On Sun, Mar 24, 2013 at 12:02 AM, Kok, Auke-jan H <auke-jan.h....@intel.com> wrote: > On Sat, Mar 23, 2013 at 3:54 PM, Kay Sievers <k...@vrfy.org> wrote: >> On Sat, Mar 23, 2013 at 11:47 PM, Lennart Poettering >> <lenn...@poettering.net> wrote: >>> On Sat, 23.03.13 23:42, Tom Gundersen (t...@jklm.no) wrote: >>> >>>> >>>> On Sat, Mar 23, 2013 at 2:16 AM, Lennart Poettering >>>> <lenn...@poettering.net> wrote: >>>> > Then, I generally believe better than trying to be smart when reading >>>> > things we should much rather try to place things properly on disk. We >>>> > already defrag things based on the read order for btrfs, we should do >>>> > the same for ext4. The API for that unfortunately awful, but e4rat has >>>> > shown that this does work. Basically, this is what you do: >>>> >>>> Isn't the problem that reads by blkid and friends are not being caught >>>> by readahead-collect, and hence end up blocking until readahead-replay >>>> has finished? In that case reordering won't help (I think). >>> >>> Hmm, if root file system is mounted the file system's superblock should >>> be cached in memory, I'd expect, so blkid shouldn't have to block... >> >> I guess it's more about ~30-40 tiny seek()/read() on the main block >> device, spread all over the place mainly the first 200 and the last >> few kilobyte of the disk, what blkid need to do. >> >> None of of that shares the cache with the mounted filesystem blocks, >> and I don't think any of that data is in any other cache at that time. > > I don't see anything in udev code setting IOPRIO... perhaps elevating > the few calls doing bklid and mount might be helpful?
Maybe that really makes a difference, we should definitely try that. The blkid calls are really limited to a few bytes here and there, and will never loop for a long time, so that should be fine. Do you have a box, where you could you give it a quick try to bump the prio for the libblkid calls: ioprio_set(IOPRIO_WHO_PROCESS, getpid(), ...) in: src/udev/udev-builtin-blkid.c ? Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
