You are here


The Linux Plumbers Conference started Wednesday. The morning storage track had someone from Oracle presenting a bunch of problems, mostly to do with asynchronous IO interfaces--e.g., how can we quickly open a few thousand files, possibly read the 1st block, and close them all? Each open necessarily takes some time (because the disk will generally have to seek a few times to find the file), but they can gain by doing a bunch of opens in parallel. (They've typically got a big array of disks so there's lots of disk-heads that can be seeking at once.) For some reason they'd rule out threading their application as a way to get parallelism--I wanted to ask why, but didn't get a chance. It clearly wasn't that they were unwilling to rewrite their applications. Other options were adding a open system call that takes a list of files, or implementing something like syslets.

And similarly she wanted more parallelism submitting IO's. Linus suggested using sys_readahead, which tells the kernel to start reading the given range into the page cache. You can run sys_readahead for a bunch of IO ranges, then go back and do reads for the same ranges to get the data. Since sys_readahead hasn't been used much, its implementation may not be perfect, but it could probably be fixed. One objection to that approach was that under memory pressure the stuff you read into the page cache might not last to the read.

Somebody else did a talk on filesystem benchmarks based on startup of a gnome application.

I went to Zach Brown's CRFS talk in the afternoon. He's making some interesting tradeoffs, in the understandable desire not to bite off too much at first. They seemed like sensible choices to me, but others were more skeptical. Then I tried to do a little work until Linus's git tutorial. It was sort of interesting to see how Linus chose to present that, and I learned an odd thing or two, but it was mostly old hat.

Afterwards Trond invited a couple of us to have dinner with the speaker at Higgins restaurant. Which was very nice.