Re: [RFC][PATCH 0/4] ZERO PAGE again v2

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Wed, 8 Jul 2009 19:32:06 +0200
Andrea Arcangeli <aarcange@redhat.com> wrote:

> On Tue, Jul 07, 2009 at 06:06:29PM +0900, KAMEZAWA Hiroyuki wrote:
> > Then,  most of users will not notice that ZERO_PAGE is not available until
> > he(she) find OOM-Killer message. This is very terrible situation for me.
> > (and most of system admins.)
> 
> Can you try to teach them to use KSM and see if they gain a while lot
> more from it (surely they also do some memset(dst, 0) sometime not
> only memcpy(zerosrc, dst)). Not to tell when they init to non zero
> values their arrays/matrix which is a bit harder to optimize for with
> zero page...
> 
Hmm, scan & take diff & merge user pages in the kernel ?
IIUC, it can be only help if zero-page's life time are verrrry long.

> My only dislike is that zero page requires a flood of "if ()" new
> branches in fast paths that benefits nothing but badly written app,
> and that's the only reason I liked its removal.
> 
I'll take Linus's suggestion "use pte_special() in vm_normal_page()".
Then, "if()" will not increase so much as expected, flood.

In usual apps which doen't use any zero-page, following path will be checked.

 - "is this WRITE fault ?" in do_anonymous_page().
 - vm_normal_page() never finds pte_special() then no more "if"s.
 - get_user_pages() etc..will have more 2-3 if()s depends on passed flags.

Anyway, I'll reduce overheads as much as possible. please see v3.
pte_special() checks (which are already used) reduce "if()" to some extent.

> For goodly (and badly) written scientific app there KSM that will do
> more than zeropage while dealing with matrix algorithms and such. If
> they try KSM and they don't gain a lot more free memory than with the
> zero page hack, then I agree in reintroducing it, but I guess when
> they try KSM they will ask you to patch kernel with it, instead of
> patch kernel with zeropage. 

Most of the difference between zeropage and KSM solution is that
zeropage requires no refcnt/rmap handling, never pollutes caches, etc.
This will be big advantage.

> If they don't gain anything more with KSM
> than with zeropage, and the kksmd overhead is too high, then it would
> make sense to use zeropage for them I agree even if it bites in the
> fast path of all apps that can't benefit from it. (not to tell the
> fact that reading zero and writing non zero back for normal apps is
> harmful as there's a double page fault generated instead of a single
> one, kksmd has a cost but zeropage isn't free either in term of page
> faults too)
> 
Sorry, my _all_ customers use RHEL5 and there are no ksm yet.

BTW, I love concepts of KSM but I don't trust KSM so much as that I recommend
it to my customers, yet. It's a bit young for production in my point of view.
AFAIK, no bug reports of ksm has reached this mailing list, yet.

Thanks,
-Kame

--
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>