[lkml]   [2002]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.19pre1aa1
On Tue, Mar 05, 2002 at 11:12:46AM -0800, Andrew Morton wrote:
> Arjan van de Ven wrote:
> >
> > On Tue, Mar 05, 2002 at 07:26:04PM +0100, Andrea Arcangeli wrote:
> >
> > > Another approch would be to add the pages backing the bh into the lru
> > > too, but then we'd need to mess with the slab and new bitflags, new
> > > methods and so I don't think it's the best solution. The only good
> > > reason for putting new kind of entries in the lru would be to age them
> > > too the same way as the other pages, but we don't need that with the bh
> > > (they're just in, and we mostly care only about the page age, not the bh
> > > age).
> >
> > For 2.5 I kind of like this idea. There is one issue though: to make
> > this work really well we'd probably need a ->prepareforfreepage()
> > or similar page op (which for page cache pages can be equal to writepage()
> > ) which the vm can use to prepare this page for freeing.
> If we stop using buffer_heads for pagecache I/O, we don't have this problem.
> I'm showing a 20% reduction in CPU load for large reads. Which is a *lot*,
> given that read load is dominated by copy_to_user.
> 2.5 is significantly less efficient than 2.4 at this time. Some of that
> seems to be due to worsened I-cache footprint, and a lot of it is due
> to the way buffer_heads now have a BIO wrapper layer.

Indeed, at the moment bio is making the thing more expensive in CPU
terms, even if OTOH it makes rawio fly.

> Take a look at submit_bh(). The writing is on the wall, guys.
> -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.090 / U:1.984 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site