Memory management

Dan Williams | 1 Jul 2008 03:57

Picon

[problem] raid performance loss with 2.6.26-rc8 on 32-bit x86 (bisected)

Hello,

Prompted by a report from a user I have bisected a performance loss
apparently introduced by commit 54a6eb5c (mm: use two zonelist that are
filtered by GFP mask).  The test is simple sequential writes to a 4 disk
raid5 array.  Performance should be about 20% greater than 2.6.25 due to
commit 8b3e6cdc (md: introduce get_priority_stripe() to improve raid456
write performance).  The sample data below shows sporadic performance
starting at 54a6eb5c.  The '+' indicates where I hand applied 8b3e6cdc.

revision   2.6.25.8-fc8 2.6.25.9+ dac1d27b+ 18ea7e71+ 54a6eb5c+ 2.6.26-rc1 2.6.26-rc8
           138          168       169       167       177       149        144
           140          168       172       170       109       138        142
           142          165       169       164       119       138        129
           144          168       169       171       120       139        135
           142          165       174       166       165       122        154
MB/s (avg) 141          167       171       168       138       137        141
% change   0%           18%       21%       19%       -2%       -3%        0%
result     base         good      good      good      [bad]     bad        bad

Notable observations:
1/ This problem does not reproduce when ARCH=x86_64, i.e. 2.6.26-rc8 and
54a6eb5c show consistent performance at 170MB/s.
2/ Single drive performance appears to be unaffected
3/ A quick test shows that raid0 performance is also sporadic:
   2147483648 bytes (2.1 GB) copied, 7.72408 s, 278 MB/s
   2147483648 bytes (2.1 GB) copied, 7.78478 s, 276 MB/s
   2147483648 bytes (2.1 GB) copied, 11.0323 s, 195 MB/s
   2147483648 bytes (2.1 GB) copied, 8.41244 s, 255 MB/s
   2147483648 bytes (2.1 GB) copied, 30.7649 s, 69.8 MB/s

(Continue reading)

KOSAKI Motohiro | 1 Jul 2008 09:01

[PATCH -mm] split_lru: fix pagevec_move_tail() doesn't treat unevictable page

even under writebacking, page can move to unevictable list.
so shouldn't pagevec_move_tail() check unevictable?

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com>

---
 mm/swap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/mm/swap.c
===================================================================
--- a/mm/swap.c
+++ b/mm/swap.c
 <at>  <at>  -116,7 +116,7  <at>  <at>  static void pagevec_move_tail(struct pag
 			zone = pagezone;
 			spin_lock(&zone->lru_lock);
 		}
-		if (PageLRU(page) && !PageActive(page)) {
+		if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
 			int lru = page_is_file_cache(page);
 			list_move_tail(&page->lru, &zone->lru[lru].list);
 			pgmoved++;

MinChan Kim | 1 Jul 2008 09:34

Picon

Re: [PATCH -mm] split_lru: fix pagevec_move_tail() doesn't treat unevictable page

On Tue, Jul 1, 2008 at 4:01 PM, KOSAKI Motohiro
<kosaki.motohiro <at> jp.fujitsu.com> wrote:
> even under writebacking, page can move to unevictable list.
> so shouldn't pagevec_move_tail() check unevictable?
>
Hi, Kosaki-san.

I can't understand this race situation.
How the page can move to unevictable list while it is under writeback?

Could you explain for me ? :)

> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com>
>
> ---
>  mm/swap.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/mm/swap.c
> ===================================================================
> --- a/mm/swap.c
> +++ b/mm/swap.c
>  <at>  <at>  -116,7 +116,7  <at>  <at>  static void pagevec_move_tail(struct pag
>                        zone = pagezone;
>                        spin_lock(&zone->lru_lock);
>                }
> -               if (PageLRU(page) && !PageActive(page)) {
> +               if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
>                        int lru = page_is_file_cache(page);
>                        list_move_tail(&page->lru, &zone->lru[lru].list);

(Continue reading)

KOSAKI Motohiro | 1 Jul 2008 09:56

Re: [PATCH -mm] split_lru: fix pagevec_move_tail() doesn't treat unevictable page

Hi Kim-san,

Thank you for good question.

> > even under writebacking, page can move to unevictable list.
> > so shouldn't pagevec_move_tail() check unevictable?
> >
> Hi, Kosaki-san.
> 
> I can't understand this race situation.
> How the page can move to unevictable list while it is under writeback?
> 
> Could you explain for me ? :)

Actually, I added below assertion and tested on stress workload.
then system crashed after 4H runnings.

----------------------------------------------
static void pagevec_move_tail(struct pagevec *pvec)
{
(snip)
                if (PageLRU(page) && !PageActive(page)) {
                        int lru = page_is_file_cache(page);
                        list_move_tail(&page->lru, &zone->lru[lru].list);
                        BUG_ON(page_lru(page) != lru);  // !!here
                        pgmoved++;
                }
        }
----------------------------------------------------

(Continue reading)

Mel Gorman | 1 Jul 2008 10:09

Picon

Re: [problem] raid performance loss with 2.6.26-rc8 on 32-bit x86 (bisected)

(Christoph's address corrected and Andys added to cc)

On (30/06/08 18:57), Dan Williams didst pronounce:
> Hello,
> 
> Prompted by a report from a user I have bisected a performance loss
> apparently introduced by commit 54a6eb5c (mm: use two zonelist that are
> filtered by GFP mask).  The test is simple sequential writes to a 4 disk
> raid5 array.  Performance should be about 20% greater than 2.6.25 due to
> commit 8b3e6cdc (md: introduce get_priority_stripe() to improve raid456
> write performance).  The sample data below shows sporadic performance
> starting at 54a6eb5c.  The '+' indicates where I hand applied 8b3e6cdc.
> 
> revision   2.6.25.8-fc8 2.6.25.9+ dac1d27b+ 18ea7e71+ 54a6eb5c+ 2.6.26-rc1 2.6.26-rc8
>            138          168       169       167       177       149        144
>            140          168       172       170       109       138        142
>            142          165       169       164       119       138        129
>            144          168       169       171       120       139        135
>            142          165       174       166       165       122        154
> MB/s (avg) 141          167       171       168       138       137        141
> % change   0%           18%       21%       19%       -2%       -3%        0%
> result     base         good      good      good      [bad]     bad        bad
> 

That is not good at all as this patch is not a straight-forward revert but
the second time it's come under suspicion.

> Notable observations:
> 1/ This problem does not reproduce when ARCH=x86_64, i.e. 2.6.26-rc8 and
> 54a6eb5c show consistent performance at 170MB/s.

(Continue reading)

MinChan Kim | 1 Jul 2008 10:16

Picon

Re: [PATCH -mm] split_lru: fix pagevec_move_tail() doesn't treat unevictable page

On Tue, Jul 1, 2008 at 4:56 PM, KOSAKI Motohiro
<kosaki.motohiro <at> jp.fujitsu.com> wrote:
> Hi Kim-san,
>
> Thank you for good question.

Thanks for good explaining.
I guess your scenario have a possibility.

If I don't have a test HPC, I will dig in source. :)

>> > even under writebacking, page can move to unevictable list.
>> > so shouldn't pagevec_move_tail() check unevictable?
>> >
>> Hi, Kosaki-san.
>>
>> I can't understand this race situation.
>> How the page can move to unevictable list while it is under writeback?
>>
>> Could you explain for me ? :)
>
> Actually, I added below assertion and tested on stress workload.
> then system crashed after 4H runnings.
>
> ----------------------------------------------
> static void pagevec_move_tail(struct pagevec *pvec)
> {
> (snip)
>                if (PageLRU(page) && !PageActive(page)) {
>                        int lru = page_is_file_cache(page);

(Continue reading)

KOSAKI Motohiro | 1 Jul 2008 10:26

[resend][PATCH -mm] split_lru: fix pagevec_move_tail() doesn't treat unevictable page


Agghh!
I am really stupid. I forgot CCed Andrew 

So, I resend this.

--------------------------------------
even under writebacking, page can move to unevictable list.
so shouldn't pagevec_move_tail() check unevictable?

if pagevec_move_tail() doesn't PageUnevictable(), 
below race can occur.

    CPU1                                       CPU2
==================================================================
1. rotate_reclaimable_page()
2. PageUnevictable(page) return 0
3. local_irq_save()
4. pagevec_move_tail()
                                       SetPageUnevictable()   //mlock?
                                       move to unevictable list
5. spin_lock(&zone->lru_lock);
6. list_move_tail(); (move to inactive list)

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com>

---
 mm/swap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(Continue reading)

Andrew Morton | 1 Jul 2008 10:53

Re: [patch 1/6] mm: Allow architectures to define additional protection bits

On Wed, 18 Jun 2008 17:32:55 -0500 shaggy <at> linux.vnet.ibm.com wrote:

> This patch allows architectures to define functions to deal with
> additional protections bits for mmap() and mprotect().
> 
> arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
> arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
> arch_validate_prot() checks for valid values of the protection bits

It'd be simpler if Paul were to merge this.  It doesn't conflict with
any pending work.

Acked-by: Andrew Morton <akpm <at> linux-foundation.org>

> Note: vm_get_page_prot() is now pretty ugly.

It is.  But afacit it generates the same code for non-powerpc.

> Suggestions?

nfi.  Let us rub the Hugh-summoning lamp.

> Signed-off-by: Dave Kleikamp <shaggy <at> linux.vnet.ibm.com>
> ---
> 
>  include/linux/mman.h |   28 +++++++++++++++++++++++++++-
>  mm/mmap.c            |    5 +++--
>  mm/mprotect.c        |    2 +-
>  3 files changed, 31 insertions(+), 4 deletions(-)
>

(Continue reading)

Benny Halevy | 1 Jul 2008 13:53

Re: [PATCH] mm: fix uninitialized variables for find_vma_prepare callers

On Jun. 30, 2008, 22:00 +0300, Hugh Dickins <hugh <at> veritas.com> wrote:
> On Mon, 30 Jun 2008, Benny Halevy wrote:
>> gcc 4.3.0 correctly emits the following warnings.
>> When a vma covering addr is found, find_vma_prepare indeed returns without
>> setting pprev, rb_link, and rb_parent.
> 
> That's amusing, thank you.
> 
> You may wonder how the vma rb_tree has been working all these years
> despite that.  The answer is that we only use find_vma_prepare when
> about to insert a new vma: if there's anything already there, it's
> either an error condition, or we go off and unmap the overlap without
> taking any interest in those uninitialized values for linking.
> 
> It would be nicer to initialize them, and your patch is certainly
> nice and simple.  Would it have the effect, that it returns with
> vma == *pprev when addr falls within an existing vma?
> That would be a sensible outcome, I think.

No, *pprev will be set to the last parent encountered with this
patch, but doing what you suggested is possible, though I doubt
it matters since apparently nobody is using pprev in this path
otherwise stuff would've just broken.

Benny

> 
> Hugh
> 
>> [warnings snipped]

(Continue reading)

Rik van Riel | 1 Jul 2008 15:38

Picon

Re: [resend][PATCH -mm] split_lru: fix pagevec_move_tail() doesn't treat unevictable page

On Tue, 01 Jul 2008 17:26:51 +0900
KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com> wrote:

> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com>

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

Good catch!

>  <at>  <at>  -116,7 +116,7  <at>  <at>  static void pagevec_move_tail(struct pag
>  			zone = pagezone;
>  			spin_lock(&zone->lru_lock);
>  		}
> -		if (PageLRU(page) && !PageActive(page)) {
> +		if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
>  			int lru = page_is_file_cache(page);
>  			list_move_tail(&page->lru, &zone->lru[lru].list);
>  			pgmoved++;

--

-- 
All rights reversed.

Group

gmane.linux.kernel.mm.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 78

Articles in period: 770

July 2008

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

[PATCH] mm/memory-failure.c: fix memory leak in successful soft offlin (17 May 2013)
readahead man page incorrectly says it blocks (17 May 2013)
[PATCH] mm/nommu.c: add additional check for vread() just like vwrite( (17 May 2013)
[PATCH] mm/page_alloc.c: add additional checking and return value for (17 May 2013)
[PATCH 0/5] Obey mark_page_accessed hint given by filesystems v3r1 (17 May 2013)
[patch v3 -mm 1/3] memcg: integrate soft reclaim tighter with zone shr (17 May 2013)
[PATCH 0/12][V3] memcg: make memcg's life cycle the same as cgroup (17 May 2013)
[PATCH] memcg: update TODO list in Documentation (17 May 2013)
[patch v3 -mm 1/3] memcg: integrate soft reclaim tighter with zone shr (17 May 2013)
[RFCv2][PATCH 0/5] mm: Batch page reclamation under shink_page_list (16 May 2013)
[PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior (16 May 2013)
[PATCH] mm: vmscan: handle any negative return value from scan_objects (16 May 2013)
[PATCH v2] mm, slab: moved kmem_cache_alloc_node comment to correct pl (16 May 2013)
[PATCH] mm, slab: corrected the comment 'kmem_cache_alloc' to 'slab_al (15 May 2013)
[PATCH] fs: bump inode and dentry counters to long (15 May 2013)
[PATCH v6 0/8] kdump, vmcore: support mmap() on /proc/vmcore (15 May 2013)
[PATCH] Fixes, cleanups, compile warning fixes, and documentation upda (14 May 2013)
[PATCH v4 00/20] change invalidatepage prototype to accept length (14 May 2013)
[3.10-rc1 SLUB?] mm: kmemcheck warning. (14 May 2013)
[PATCH 3/3] mm/kmemleak.c: Merge the consecutive scan-areas. (14 May 2013)
[PATCH 2/3] mm/kmemleak.c: Use list_for_each_entry_safe to reconstruct (14 May 2013)

Archives

880	May 2013
1622	April 2013
1206	March 2013
1024	February 2013
1388	January 2013
1117	December 2012
2037	November 2012
1595	October 2012
1175	September 2012
1548	August 2012
1342	July 2012
1797	June 2012
1452	May 2012
1140	April 2012
1265	March 2012
1181	February 2012
1091	January 2012
962	December 2011
1154	November 2011
766	October 2011
954	September 2011
1065	August 2011
728	July 2011
1496	June 2011
1385	May 2011
1362	April 2011
1638	March 2011
814	February 2011
761	January 2011
790	December 2010
1370	November 2010
1063	October 2010
867	September 2010
1152	August 2010
1048	July 2010
1114	June 2010
929	May 2010
1403	April 2010
1374	March 2010
881	February 2010
1211	January 2010
928	December 2009
919	November 2009
717	October 2009
1042	September 2009
1146	August 2009
1008	July 2009
1520	June 2009
1294	May 2009
1069	April 2009
1204	March 2009
783	February 2009
563	January 2009
674	December 2008
867	November 2008
1056	October 2008
569	September 2008
380	August 2008
770	July 2008
768	June 2008
812	May 2008
794	April 2008
1116	March 2008
872	February 2008
1128	January 2008
295	December 2007
543	November 2007
665	October 2007
482	September 2007
864	August 2007
716	July 2007
445	June 2007
955	May 2007
662	April 2007
602	March 2007
448	February 2007
420	January 2007
176	December 2006
222	November 2006
304	October 2006
239	September 2006
426	August 2006
142	July 2006
279	June 2006
309	May 2006
317	April 2006
307	March 2006
117	February 2006
333	January 2006
244	December 2005
566	November 2005
292	October 2005
207	September 2005
69	August 2005
164	July 2005
280	June 2005
348	May 2005
212	April 2005
181	March 2005
269	February 2005
364	January 2005
348	December 2004
442	November 2004
304	October 2004
189	September 2004
250	August 2004
115	July 2004
106	June 2004
163	May 2004
133	April 2004
129	March 2004
375	February 2004
240	January 2004
81	December 2003
132	November 2003
85	October 2003
133	September 2003
188	August 2003
326	July 2003
214	June 2003
381	May 2003
307	April 2003
206	March 2003
191	February 2003
198	January 2003
107	December 2002
166	November 2002
401	October 2002
397	September 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template