Note: This is my own opinion, and not that of my employer (Google) or based on trade secrets or other IP from my employer.
Keeping pre-erased blocks is useful, but it can only reduce the write latency to what the chip gives you. And the chip gives you a longer write latency than read latency, especially for MLC with smaller process sizes.
True, there is a difference between read and write latency, but at least that is consistent and therefore easy to plan for. Large variance makes things far more difficult, in my opinion.
Note: This is my own opinion, and not that of my employer (Google) or based on trade secrets or other IP from my employer.
I don't know if this is actually true in SSDs that are actually used, but there is a real cost/write-performance tradeoff. You can make writes faster by using SLC rather than MLC and by having a higher proportion of physical capacity to reported capacity in order to reduce write amplification. Looking into the future, there could be a journal in an even faster kind of memory like PCM or memristors. Still, the controller can only do so much to hide the properties of the chip, and if your drive is only flash, then the trend in the recent past for the chips is that reads are getting faster and writes are getting slower (based on the move towards smaller process sizes and more levels).
Lwn and linuxnewbies aren't perfect, but they're some of the best resources we have. There are also a few books out there that are pretty useful, but they are always out of date. No need to start from scratch and replace these things;it's easier to just work on improving what we have already.
Linux is a huge program developed by tons of people over decades with limited focus on docs in the past and high code turnover today. Getting useful information about it is just hard.
Can we really credit this entirely to the increased efficiency of iPads? There are lots of usages of RAM--now people carry around cell phones with more RAM than before. And data centers can make use of tons of RAM--the main constraint is its price.
Maybe this is actually a result of bad general macroeconomic conditions. Nobody wants to spend too much money, whether it's consumers or people setting up data centers. That's always been the case, but we're poorer than before now, and RAM is one of those things that you can cut down on, or stop increasing as quickly on.
>And data centers can make use of tons of RAM--the main constraint is its price.
price through several aspects. Among the main constraints is the number of memory slots (as we have mainly 4Gb and 8Gb RAM modules to work with). And 8Gb ECC (ECC/registered memory is the only way to utilize more than 4 slots per CPU) is only recently became reasonably priced (ie. close to 2x4GB). Once the slots are filled with 4GB modules - throw and replace with 8GB. Painful. Once filled with 8Gb modules - replace the motherboard+CPUs. With what? There is of course monsters around - http://www.provantage.com/supermicro-mbd-x8qb6-f~ASUPM3AU.ht...
which require monster priced CPUs :)
So, thanks to manufacturers for the cheap 4Gb and 8Gb, yet if they built the large overcapacities for these modules instead of gearing up to 16Gb - that would explain their financial problems.
Ah, I did, and he slightly more than tripled my RSUs (from 150 to 500), but left my base the same. Which is also weird since that base is lower than my current one.
That's about $50K/yr, assuming a 4-year vest and today's price range. Nice job.
I assume they give out RSU more than cash because it's a better-aligned incentive (both in motivations and risk profile), and it makes your x% raise cheaper next year.
Why do you want to do this, anyway? Linux already isolates processes' memory from each other. With cgroups you can ensure that resources are allocated fairly, and with chroot and namespaces you can ensure that they're securely isolated from each other. Why run a whole bunch of kernels on top of other kernels? It just adds inefficiency.
A couple ways to prevent X11 keylogging/screenshots/actions:
* If chrome/chromium are doing it right now, most parts of the browser should not be able to access X11 directly.
* X.org provides for two compartiments, trusted X (the default) and untrusted X (now used by ssh -X, also sux --untrusted). There are still a number of applications having issues with untrusted X (e.g. Skype doesn't work), also copy & paste don't normally work (for that you can use "xsel -o | ssh otheruser@localhost 'DISPLAY=:1 xsel -i'" or converse, bound to a key combination or panel widget), but it works well enough that I'm running Twinkle and xchat that way.
* let the apps go through VNC (Skype has issues with this, too, though, but then Skype doesn't run smoothly in a VM either (realtime audio issues))
Of course the kernel (and suid apps and apps with tempfile races etc.) are still offering a broader attack surface than a VM, so the above should be complemented with some good intrusion detection mechanism (to catch intrusions before they exploit root), for which I don't have a good suggestion.
Good point about C. You misunderstand the intent of my post though.
First, as a small point, I was not seriously suggesting using thread pools to implement mlock_eventfd. That's just a way that we could play around with it short of a kernel implementation, which would probably be more efficient.
Second, I don't think I'm dogmatic about mmap. It's just a cool interface that would be nice to see more widely used, and I was suggesting that it might be more usable with a small addition. Commenters here, at my blog and on Reddit have pointed out other problems, and I'm happy to learn about these. If mmap isn't good and we should keep using DIO, then I think there are still possible improvements that we could make to the interface to allow better cooperation with the kernel.
I don't get it. He was spending $40,000/month on his living expenses while being afraid that he wouldn't be able to afford diapers and food for his baby? How was this guy running his life so wrong? Did it somehow cost him that much to maintain his unsellable house in the financial district of New York? Are we supposed to feel sympathy for him?
EDIT: I've deleted my comment and my other replies to this discussion. As irrational as it is, my silly e-psyche recognizes it's easy to hit the delete button rather than watch my opinion down-arrowed.
Maybe he should. I write for a publisher whose offices are more than a thousand miles away from me. We have this nifty thing called the Internet now, and postal mail works even when you don't live in the same city anyway (postal mail being how most book proposals and manuscripts are delivered when they are not sent digitally). Even if you have to fly halfway across the country twice a year for meetings, which is more often than many people would have to actually meet face-to-face with editors at publishers (judging by my limited experience at least), it costs less than sweet digs in the financial district of one of the most expensive cities in the world.
Yep, that's basically what we do. User-level threads are called 'coroutines' and they're scheduled cooperatively, so they don't incur the overhead of user-level preemption. Cooperative scheduling is fine for us because we can ensure that a single coroutine won't hog the CPU or issue blocking system calls.
It'd be nice if some pthread implementation gave us what we need, but I don't think they do. They probably are too heavy an abstraction, even if implemented in user space, providing too strong guarantees for context switching and scheduling. For example, we're never going to set individual signal handlers on different coroutines, but pthreads guarantee this capability. So even user-level pthreads which don't support preemption will require a system call on context switches, just as ucontext.h's swapcontext does for similar reasons. But as Slava points out, the performance penalty is something that we need to verify in the future with benchmarks.
What would be really nice is if the OS, or at least a standard application framework usable from C++, supported this. But it doesn't, so we build our own.
Keeping pre-erased blocks is useful, but it can only reduce the write latency to what the chip gives you. And the chip gives you a longer write latency than read latency, especially for MLC with smaller process sizes.