Re: [RFC] Parallelize IO for e2fsck

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Bodo Eggert <7eggert@...>
Cc: Bodo Eggert <7eggert@...>, Andreas Dilger <adilger@...>, Andreas Dilger <adilger@...>, Alan Cox <alan@...>, Adrian Bunk <bunk@...>, David Chinner <dgc@...>, <linux-ext4@...>, <linux-fsdevel@...>, <linux-kernel@...>, Ric Wheeler <ric@...>, Theodore Tso <tytso@...>, Valerie Henson <val@...>, <Valdis.Kletnieks@...>
Date: Friday, January 25, 2008 - 9:55 pm

>> Incidentally, some context for the AIX approach to the OOM problem: a 
places 
The 
was 
similar 

It's the way virtual memory always worked when it was first invented.  The 
system not only reserved space to back every page of virtual memory; it 
assigned the particular blocks for it.  Late allocation was a later 
innovation, and I believe its main goal was to make it possible to use the 
cheaper disk drives for paging instead of drums.  Late allocation gives 
you better locality on disk, so the seeking doesn't eat you alive (drums 
don't seek).  Even then, I assume (but am not sure) that the system at 
least reserved the space in an account somewhere so at pageout time there 
was guaranteed to be a place to which to page out.  Overcommitting page 
space to save on disk space was a later idea.

I was surprised to see AIX do late allocation by default, because IBM's 
traditional style is bulletproof systems.  A system where a process can be 
killed at unpredictable times because of resource demands of unrelated 
processes doesn't really fit that style.

It's really a fairly unusual application that benefits from late 
allocation: one that creates a lot more virtual memory than it ever 
touches.  For example, a sparse array.  Or am I missing something?

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [RFC] Parallelize IO for e2fsck, Bodo Eggert, (Thu Jan 24, 1:32 pm)
Re: [RFC] Parallelize IO for e2fsck, Adrian Bunk, (Thu Jan 24, 7:08 pm)
Re: [RFC] Parallelize IO for e2fsck, Theodore Tso, (Thu Jan 24, 7:40 pm)
Re: [RFC] Parallelize IO for e2fsck, KOSAKI Motohiro, (Sat Jan 26, 8:32 am)
Re: [RFC] Parallelize IO for e2fsck, Bryan Henderson, (Fri Jan 25, 2:03 pm)
Re: [RFC] Parallelize IO for e2fsck, Bodo Eggert, (Fri Jan 25, 7:01 pm)
Re: [RFC] Parallelize IO for e2fsck, Bryan Henderson, (Fri Jan 25, 9:55 pm)
Re: [RFC] Parallelize IO for e2fsck, Theodore Tso, (Sat Jan 26, 9:21 am)
Re: [RFC] Parallelize IO for e2fsck, Zan Lynx, (Thu Jan 24, 8:25 pm)
Re: [RFC] Parallelize IO for e2fsck, Andreas Dilger, (Fri Jan 25, 7:09 am)
Re: [RFC] Parallelize IO for e2fsck, Zan Lynx, (Fri Jan 25, 8:55 pm)
Re: [RFC] Parallelize IO for e2fsck, KOSAKI Motohiro, (Sat Jan 26, 7:56 am)
Re: [RFC] Parallelize IO for e2fsck, Andreas Dilger, (Thu Jan 24, 6:07 pm)