Andrea Arcangeli wrote:
> [ big snip. Addressed in other email ]
> it should be simple, mainline swapouts more, so it's less likely to
> trash away some useful cache.
> just try -aa after a:
> echo 10 >/proc/sys/vm/vm_mapped_ratio
> it should swapout more and better preserve the cache.
-aa swapout balancing seems very good indeed to me.
> > > > In my swapless testing, I burnt HUGE amounts of CPU in flush_tlb_others().
> > > > So we're madly trying to swap pages out and finding that there's no swap
> > > > space. I beleive that when we find there's no swap left we should move
> > > > the page onto the active list so we don't keep rescanning it pointlessly.
> > >
> > > yes, however I think the swap-flood with no swap isn't a very
> > > interesting case to optimize.
> > Running swapless is a valid configuration, and the kernel is doing
> I'm not saying it's not valid or non interesting.
> It's the mix "I'm running out of memory and I'm swapless" that is the
> case not interesting to optimize.
> If you're swapless it means you've enough memory and that you're not
> running out of swap. Otherwise _you_ (not the kernel) are wrong not
> having swap.
um. Spose so.
> > The VM code lacks comments, and nobody except yourself understands
> > what it is supposed to be doing. That's a bug, don't you think?
> Lack of documentation is not a bug, period. Also it's not true that I'm
> the only one who understands it. For istance Linus understand it
> completly, I am 100% sure.
> Anyways I wrote a dozen of slides on the VM with some graph showing the
> design of the VM if anybody can better learn from a slide than from the
That's good. Your elevator design slides were very helpful. However
offline documentation tends to go stale. A nice big block comment
maintained by a programmer who cares goes a loooog way.
> I believe the slides are useful to understand the design, but if you
> want to change one line of code slides or not you've to read the code.
> Everybody is complaining about documentation. This is a red-herring.
> There's no documentation that allows you to hack the previous VM code.
> I'd ask how many of the people happy with the previous documentation
> were effectively VM developers. Except for some possible misleading
> comment in the current code that we may have not updated yet, I don't
> think there's been a regression in documentation.
Sigh. Just because the current core kernel looks like it was
scrawled in crayon by an infant doesn't mean that everyone has
to eschew literate, mature, competent and maintainable programming
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:22 EST