Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix

[Pavel Machek]

Hi!

> > > > An anonymous user page meets these requirements.  A did say "anal", but
> > > > rw_swap_page_sync() is a general-purpose library function and we shouldn't
> > > > be making assumptions about the type of page which the caller happens to be
> > > > feeding us.
> > > 
> > > that is a specialized backdoor to do I/O on _private_ pages, it's not a
> > > general-purpose library function for doing anonymous pages
> > > swapin/swapout, infact the only user is swap susped and we'd better
> > > forbid swap suspend to pass anonymous pages through that interface and
> > > be sure that nobody will ever attempt anything like that.
> > > 
> > > that interface is useful only to reach the swap device, for doing I/O on
> > > private pages outside the VM, in the old days that was used to
> > > read/write the swap header (again on a private page), swap suspend is
> > > using it for similar reasons on _private_ pages.
> > 
> > Ahha, so *here* is that discussion happening. I was only seeing it at
> > bugzilla, and could not make sense of it.
> 
> ;)
> 
> btw, as far as I can tell I cannot see anymore VM issues with current CVS
> kernel, what I get now is:

What does "current CVS kernel" mean? Current one at bkcvs?

> > If swsusp/pmdisk are only user of rw_swap_page_sync, perhaps it should
> > be moved to power/ directory?
> 
> it's ok to leave it in page_io.c since it's generating a fake-swapcache
> entry, and there are writeback details etc.. that'd better stay in the
> mm layer.

Ok.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/