On Thu, 2006-03-23 at 10:15 -0800, Linus Torvalds wrote:
>
> On Thu, 23 Mar 2006, Marcelo Tosatti wrote:
> >
> > IMHO the page replacement framework intent is wider than fixing the
> > currently known performance problems.
> >
> > It allows easier implementation of new algorithms, which are being
> > invented/adapted over time as necessity appears.
>
> Yes and no.
>
> It smells wonderful for a pluggable page replacement standpoint, but
> here's a couple of observations/questions:
> a) the current one actually seems to have beaten the on-comers (except
> for loads that were actually made up to try to defeat LRU)
> b) is page replacement actually a huge issue?
>
> Now, the reason I ask about (b) is that these days, you buy a Mac Mini,
> and it comes with half a gig of RAM, and some apple users seem to worry
> about the fact that the UMA graphics removes 50MB or something of that is
> a problem.
>
> IOW, just under half a _gigabyte_ of RAM is apparently considered to be
> low end, and this is when talking about low-end (modern) hardware!
>
> And don't tell me that the high-end people care, because both databases
> (high end commercial) and video/graphics editing (high end desktop) very
> much do _not_ care, since they tend to try to do their own memory
> management anyway.
Sure, however there is quite a large group in between. Especially the
desktop users.
For example see this thread:
http://lkml.org/lkml/2006/3/23/25
where Jens says:
http://lkml.org/lkml/2006/3/23/39
Typical desktop use cases that hit page-reclaim are things like
burning/copying/unrar'ing dvd images. Also bittorrent can hit the
page-cache quite hard.
Not to mention memory hogs such as Gnome and OpenOffice.
Other things that hit my page-cache are: git, cscope and grep.
> > One example (which I mentioned several times) is power saving:
> >
> > PB-LRU: A Self-Tuning Power Aware Storage Cache Replacement Algorithm
> > for Conserving Disk Energy.
>
> Please name a load that really actually hits the page replacement today.
>
> It smells like university research to me.
>
> And don't flame me: I'm perfectly happy to be shown to be wrong. I just
> get a very strong feeling that the people who care about tight memory
> conditions and perhaps about page replacement are the same people who
> think that our kernel is too big - the embedded people. And somehow I'm
> not convinced they want the added abstraction either - they'd probably
> rather just have a smaller kernel ;)
Well, I for one am not an embedded user, not have any interrests in that
direction.
As for the added abstraction, I find that having abstraction layers is
generaly good - it forces one to think on the concepts involved.
Layering violations become painfully clear.
> What I'm trying to say is that page replacement hasn't been what seems to
> have worried people over the last year or two. We had some ugly problems
> in the early 2.4.x timeframe, and I'll claim that most (but not all) of
> those were related to highmem/zoning issues which we largely solved. Which
> was about page replacement, but really a very specific issue within that
> area.
As Rik said, is would be good to have the VM work in more cases.
> So seriously, I suspect Andrew's "Holy cow" comes from the fact that he is
> more worried about VM maintainability and stability than page replacement.
> I certainly am.
I can understand this with regard to having more than one policy in the
kernel. However I feel that if the abstraction is maintained, the
stock-kernel could just carry one, preferably CLOCK-Pro. This should
greatly reduce the maintenance burden.
However PB-LRU might be very interresting for laptop users (haven't
looked into that one yet though so just rambling here).
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
