Re: [PATCH 00/23] per device dirty throttling -v8

In addition, big server boxes are usually not reading a huge *number*
of files per second.  The place where you see this as a problem is (a)
compilation, thanks to huge /usr/include hierarchies (and here things
have gotten worse over time as include files have gotten much more
complex than in the early Unix days), and (b) silly desktop apps that
want to scan huge numbers of XML files or who want to read every
single image file on the desktop or in an open file browser window to
show c00l icons.  Oh, and I guess I should include Maildir setups.

If you are always reading from the same small set of files (i.e., a
database workload), then those inodes only get updated every 5 seconds
(the traditional/default metadata update sync time, as well as the
default ext3 journal update time), it's no big deal.  Or if you are
running a mail server, most of the time the mail queue files are
getting updated anyway as you process them, and usually the mail is
delivered before 5 seconds is up anyway.  

it's just one of those things that get compounded with journaling
filesystems though..... a single async write that happens "sometime in
the future" is one thing... having a full transaction (which acts as
barrier and synchronisation point) is something totally worse.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>