headers
KAMEZAWA Hiroyuki | 1 Apr 2009 01:57
Favicon

Re: [PATCH 4/4] add ksm kernel shared memory driver.

On Tue, 31 Mar 2009 15:21:53 +0300
Izik Eidus <ieidus <at> redhat.com> wrote:
> >   
> kpage is actually what going to be KsmPage -> the shared page...
> 
> Right now this pages are not swappable..., after ksm will be merged we 
> will make this pages swappable as well...
> 
sure.

> > If so, please
> >  - show the amount of kpage
> >  
> >  - allow users to set limit for usage of kpages. or preserve kpages at boot or
> >    by user's command.
> >   
> 
> kpage actually save memory..., and limiting the number of them, would 
> make you limit the number of shared pages...
> 

Ah, I'm working for memory control cgroup. And *KSM* will be out of control.
It's ok to make the default limit value as INFINITY. but please add knobs.

Thanks,
-Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ying Han | 1 Apr 2009 02:17
Picon
Favicon

Re: [RFC v2][PATCH]page_fault retry with NOPAGE_RETRY

Thanks Andrew. I have the patches for all the arches and i just need
to clean them up a little bit. I will send them to you ASAP.

--Ying

On Tue, Mar 31, 2009 at 3:00 PM, Andrew Morton
<akpm <at> linux-foundation.org> wrote:
> On Fri, 5 Dec 2008 11:40:19 -0800
> Ying Han <yinghan <at> google.com> wrote:
>
>> changelog[v2]:
>> - reduce the runtime overhead by extending the 'write' flag of
>>   handle_mm_fault() to indicate the retry hint.
>> - add another two branches in filemap_fault with retry logic.
>> - replace find_lock_page with find_lock_page_retry to make the code
>>   cleaner.
>>
>> todo:
>> - there is potential a starvation hole with the retry. By the time the
>>   retry returns, the pages might be released. we can make change by holding
>>   page reference as well as remembering what the page "was"(in case the
>>   file was truncated). any suggestion here are welcomed.
>>
>> I also made patches for all other arch. I am posting x86_64 here first and
>> i will post others by the time everyone feels comfortable of this patch.
>
> I'm about to send this into Linus.  What happened to the patches for
> other architectures?
>
> Please send them over when convenient and I'll work on getting them
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik van Riel | 1 Apr 2009 04:10
Picon
Favicon

Re: [patch 2/6] Guest page hinting: volatile swap cache.

Martin Schwidefsky wrote:
> From: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
> From: Hubertus Franke <frankeh <at> watson.ibm.com>
> From: Himanshu Raj
> 
> The volatile page state can be used for anonymous pages as well, if
> they have been added to the swap cache and the swap write is finished.

> Signed-off-by: Martin Schwidefsky <schwidefsky <at> de.ibm.com>

Acked-by: Rik van Riel <riel <at> redhat.com>

--

-- 
All rights reversed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 1 comment |
headers
Rik van Riel | 1 Apr 2009 04:52
Picon
Favicon

Re: [patch 3/6] Guest page hinting: mlocked pages.

Martin Schwidefsky wrote:
> From: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
> From: Hubertus Franke <frankeh <at> watson.ibm.com>
> From: Himanshu Raj
> 
> Add code to get mlock() working with guest page hinting. The problem
> with mlock is that locked pages may not be removed from page cache.
> That means they need to be stable. 

> Signed-off-by: Martin Schwidefsky <schwidefsky <at> de.ibm.com>

Acked-by: Rik van Riel <riel <at> redhat.com>

--

-- 
All rights reversed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 1 comment |
headers
Johannes Weiner | 1 Apr 2009 06:09

Re: [PATCH] vmscan: memcg needs may_swap (Re: [patch] vmscan: rename sc.may_swap to may_unmap)

On Tue, Mar 31, 2009 at 10:48:32AM +0900, KOSAKI Motohiro wrote:
> > > Sorry for too late response.
> > > I don't know memcg well.
> > > 
> > > The memcg managed to use may_swap well with global page reclaim until now.
> > > I think that was because may_swap can represent both meaning.
> > > Do we need each variables really ?
> > > 
> > > How about using union variable ?
> > 
> > or Just removing one of them  ?
> 
> I hope all may_unmap user convert to using may_swap.
> may_swap is more efficient and cleaner meaning.

How about making may_swap mean the following:

	 <at>  <at>  -642,6 +639,8  <at>  <at>  static unsigned long shrink_page_list(st
	 		 * Try to allocate it some swap space here.
	 		 */
	 		if (PageAnon(page) && !PageSwapCache(page)) {
	+			if (!sc->map_swap)
	+				goto keep_locked;
	 			if (!(sc->gfp_mask & __GFP_IO))
	 				goto keep_locked;
	 			if (!add_to_swap(page))

try_to_free_pages() always sets it.

try_to_free_mem_cgroup_pages() sets it depending on whether it really
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daisuke Nishimura | 1 Apr 2009 07:08
Picon
Picon

Re: [PATCH] vmscan: memcg needs may_swap (Re: [patch] vmscan: rename sc.may_swap to may_unmap)

On Wed, 1 Apr 2009 06:09:51 +0200, Johannes Weiner <hannes <at> cmpxchg.org> wrote:
> On Tue, Mar 31, 2009 at 10:48:32AM +0900, KOSAKI Motohiro wrote:
> > > > Sorry for too late response.
> > > > I don't know memcg well.
> > > > 
> > > > The memcg managed to use may_swap well with global page reclaim until now.
> > > > I think that was because may_swap can represent both meaning.
> > > > Do we need each variables really ?
> > > > 
> > > > How about using union variable ?
> > > 
> > > or Just removing one of them  ?
> > 
> > I hope all may_unmap user convert to using may_swap.
> > may_swap is more efficient and cleaner meaning.
> 
> How about making may_swap mean the following:
> 
> 	 <at>  <at>  -642,6 +639,8  <at>  <at>  static unsigned long shrink_page_list(st
> 	 		 * Try to allocate it some swap space here.
> 	 		 */
> 	 		if (PageAnon(page) && !PageSwapCache(page)) {
> 	+			if (!sc->map_swap)
> 	+				goto keep_locked;
> 	 			if (!(sc->gfp_mask & __GFP_IO))
> 	 				goto keep_locked;
> 	 			if (!add_to_swap(page))
> 
but it doesn't work for shmem/tmpfs, does it?
So, I did in my first patch like:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Schwidefsky | 1 Apr 2009 10:13
Picon
Favicon

Re: [patch 2/6] Guest page hinting: volatile swap cache.

On Tue, 31 Mar 2009 22:10:48 -0400
Rik van Riel <riel <at> redhat.com> wrote:

> Martin Schwidefsky wrote:
> > From: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
> > From: Hubertus Franke <frankeh <at> watson.ibm.com>
> > From: Himanshu Raj
> > 
> > The volatile page state can be used for anonymous pages as well, if
> > they have been added to the swap cache and the swap write is finished.
> 
> > Signed-off-by: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
> 
> Acked-by: Rik van Riel <riel <at> redhat.com>

Thanks you for the review. I'll add the Acked-by.

--

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Schwidefsky | 1 Apr 2009 10:13
Picon
Favicon

Re: [patch 3/6] Guest page hinting: mlocked pages.

On Tue, 31 Mar 2009 22:52:04 -0400
Rik van Riel <riel <at> redhat.com> wrote:

> Martin Schwidefsky wrote:
> > From: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
> > From: Hubertus Franke <frankeh <at> watson.ibm.com>
> > From: Himanshu Raj
> > 
> > Add code to get mlock() working with guest page hinting. The problem
> > with mlock is that locked pages may not be removed from page cache.
> > That means they need to be stable. 
> 
> > Signed-off-by: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
> 
> Acked-by: Rik van Riel <riel <at> redhat.com>

I'll add this one as well. Thanks again.

--

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
(Continue reading)

Permalink | Reply | 0 comments |
headers
KOSAKI Motohiro | 1 Apr 2009 10:38
Favicon

Re: add_to_swap_cache with GFP_ATOMIC ?

(cc to related person)

> The questionable one is add_to_swap (when vmscanning), which calls
> it with __GFP_HIGH|__GFP_NOMEMALLOC|__GFP_NOWARN, i.e. GFP_ATOMIC
> plus __GFP_NOMEMALLOC|__GFP_NOWARN.  That one I have wondered
> about from time to time: GFP_NOIO would be the obvious choice,
> that's what swap_writepage will use to allocate bio soon after.
> 
> I've been tempted to change it, but afraid to touch that house
> of cards, and afraid of long testing and justification required.
> Would it be safe to drop that __GFP_HIGH?  What's the effect of the
> __GFP_NOMEMALLOC (we've layer on layer of tweak this one way because
> we're in the reclaim path so let it eat more, then tweak it the other
> way because we don't want it to eat up _too_ much).  I just let it stay.

firstly, following some patch indicate add_to_swap() parameter history.

ac47b003d03c2a4f28aef1d505b66d24ad191c4f(Hugh, Jan 6 2009) reverted 
1480a540c98525640174a7eadd712378fcd6fd63(Cristoph, Jan 8 2006).

bd53b714d32a29bdf33009f812e295667e92b930(Nick, May 1 2005) added
__GFP_NOMEMALLOC. __GFP_NOMEMALLOC mean "please don't eat emergency memory".

c4b3efde0744e038d16b33d18110d39e762ef80c(akpm, Jan 6 2003) explained
why no using emergency memory is better.
it said 

    In the case of adding pages to swapcache we're still using GFP_ATOMIC, so
    these addition attempts can still fail.  That's OK, because the error is
    handled and, unlike file pages, it will not cause user applicaton failures.
(Continue reading)

Permalink | Reply | 0 comments |
headers
KAMEZAWA Hiroyuki | 1 Apr 2009 11:04
Favicon

Re: [PATCH] vmscan: memcg needs may_swap (Re: [patch] vmscan: rename sc.may_swap to may_unmap)

On Wed, 1 Apr 2009 06:09:51 +0200
Johannes Weiner <hannes <at> cmpxchg.org> wrote:

> On Tue, Mar 31, 2009 at 10:48:32AM +0900, KOSAKI Motohiro wrote:
> > > > Sorry for too late response.
> > > > I don't know memcg well.
> > > > 
> > > > The memcg managed to use may_swap well with global page reclaim until now.
> > > > I think that was because may_swap can represent both meaning.
> > > > Do we need each variables really ?
> > > > 
> > > > How about using union variable ?
> > > 
> > > or Just removing one of them  ?
> > 
> > I hope all may_unmap user convert to using may_swap.
> > may_swap is more efficient and cleaner meaning.
> 
> How about making may_swap mean the following:
> 
> 	 <at>  <at>  -642,6 +639,8  <at>  <at>  static unsigned long shrink_page_list(st
> 	 		 * Try to allocate it some swap space here.
> 	 		 */
> 	 		if (PageAnon(page) && !PageSwapCache(page)) {
> 	+			if (!sc->map_swap)
> 	+				goto keep_locked;
> 	 			if (!(sc->gfp_mask & __GFP_IO))
> 	 				goto keep_locked;
> 	 			if (!add_to_swap(page))
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane