Memory management

Balbir Singh | 1 Jun 2009 01:51

Picon

Re: [RFC] Low overhead patches for the memory cgroup controller (v2)

* KAMEZAWA Hiroyuki <kamezawa.hiroyu <at> jp.fujitsu.com> [2009-05-18 19:11:07]:

> On Fri, 15 May 2009 23:46:39 +0530
> Balbir Singh <balbir <at> linux.vnet.ibm.com> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu <at> jp.fujitsu.com> [2009-05-16 02:45:03]:
> > 
> > > Balbir Singh wrote:
> > > > Feature: Remove the overhead associated with the root cgroup
> > > >
> > > > From: Balbir Singh <balbir <at> linux.vnet.ibm.com>
> > > >
> > > > This patch changes the memory cgroup and removes the overhead associated
> > > > with LRU maintenance of all pages in the root cgroup. As a side-effect, we
> > > > can
> > > > no longer set a memory hard limit in the root cgroup.
> > > >
> > > > A new flag is used to track page_cgroup associated with the root cgroup
> > > > pages. A new flag to track whether the page has been accounted or not
> > > > has been added as well.
> > > >
> > > > Review comments higly appreciated
> > > >
> > > > Tests
> > > >
> > > > 1. Tested with allocate, touch and limit test case for a non-root cgroup
> > > > 2. For the root cgroup tested performance impact with reaim
> > > >
> > > >
> > > > 		+patch		mmtom-08-may-2009

(Continue reading)

Hisashi Hifumi | 1 Jun 2009 03:39

Picon

Re: [PATCH] readahead:add blk_run_backing_dev


At 11:23 09/05/28, KOSAKI Motohiro wrote:
>> Hi Andrew.
>> Please merge following patch.
>> Thanks.
>> 
>> ---
>> 
>> I added blk_run_backing_dev on page_cache_async_readahead
>> so readahead I/O is unpluged to improve throughput on 
>> especially RAID environment. 
>> 
>> Following is the test result with dd.
>> 
>> #dd if=testdir/testfile of=/dev/null bs=16384
>> 
>> -2.6.30-rc6
>> 1048576+0 records in
>> 1048576+0 records out
>> 17179869184 bytes (17 GB) copied, 224.182 seconds, 76.6 MB/s
>> 
>> -2.6.30-rc6-patched
>> 1048576+0 records in
>> 1048576+0 records out
>> 17179869184 bytes (17 GB) copied, 206.465 seconds, 83.2 MB/s
>> 
>> My testing environment is as follows:
>> Hardware: HP DL580 
>> CPU:Xeon 3.2GHz *4 HT enabled
>> Memory:8GB

(Continue reading)

KOSAKI Motohiro | 1 Jun 2009 04:23

Re: [PATCH] readahead:add blk_run_backing_dev

> 
> At 11:23 09/05/28, KOSAKI Motohiro wrote:
> >> Hi Andrew.
> >> Please merge following patch.
> >> Thanks.
> >> 
> >> ---
> >> 
> >> I added blk_run_backing_dev on page_cache_async_readahead
> >> so readahead I/O is unpluged to improve throughput on 
> >> especially RAID environment. 
> >> 
> >> Following is the test result with dd.
> >> 
> >> #dd if=testdir/testfile of=/dev/null bs=16384
> >> 
> >> -2.6.30-rc6
> >> 1048576+0 records in
> >> 1048576+0 records out
> >> 17179869184 bytes (17 GB) copied, 224.182 seconds, 76.6 MB/s
> >> 
> >> -2.6.30-rc6-patched
> >> 1048576+0 records in
> >> 1048576+0 records out
> >> 17179869184 bytes (17 GB) copied, 206.465 seconds, 83.2 MB/s
> >> 
> >> My testing environment is as follows:
> >> Hardware: HP DL580 
> >> CPU:Xeon 3.2GHz *4 HT enabled
> >> Memory:8GB

(Continue reading)

Wu Fengguang | 1 Jun 2009 04:37

Picon

Re: [PATCH] readahead:add blk_run_backing_dev

On Wed, May 27, 2009 at 11:06:37AM +0800, Hisashi Hifumi wrote:
> 
> At 11:57 09/05/27, Wu Fengguang wrote:
> >On Wed, May 27, 2009 at 10:47:47AM +0800, Hisashi Hifumi wrote:
> >> 
> >> At 11:36 09/05/27, Wu Fengguang wrote:
> >> >On Wed, May 27, 2009 at 10:21:53AM +0800, Hisashi Hifumi wrote:
> >> >>
> >> >> At 11:09 09/05/27, Wu Fengguang wrote:
> >> >> >On Wed, May 27, 2009 at 08:25:04AM +0800, Hisashi Hifumi wrote:
> >> >> >>
> >> >> >> At 08:42 09/05/27, Andrew Morton wrote:
> >> >> >> >On Fri, 22 May 2009 10:33:23 +0800
> >> >> >> >Wu Fengguang <fengguang.wu <at> intel.com> wrote:
> >> >> >> >
> >> >> >> >> > I tested above patch, and I got same performance number.
> >> >> >> >> > I wonder why if (PageUptodate(page)) check is there...
> >> >> >> >>
> >> >> >> >> Thanks!  This is an interesting micro timing behavior that
> >> >> >> >> demands some research work.  The above check is to confirm if it's
> >> >> >> >> the PageUptodate() case that makes the difference. So why that case
> >> >> >> >> happens so frequently so as to impact the performance? Will it also
> >> >> >> >> happen in NFS?
> >> >> >> >>
> >> >> >> >> The problem is readahead IO pipeline is not running smoothly, which is
> >> >> >> >> undesirable and not well understood for now.
> >> >> >> >
> >> >> >> >The patch causes a remarkably large performance increase.  A 9%
> >> >> >> >reduction in time for a linear read? I'd be surprised if the workload
> >> >> >>

(Continue reading)

Hisashi Hifumi | 1 Jun 2009 04:51

Picon

Re: [PATCH] readahead:add blk_run_backing_dev


At 11:37 09/06/01, Wu Fengguang wrote:
>On Wed, May 27, 2009 at 11:06:37AM +0800, Hisashi Hifumi wrote:
>> 
>> At 11:57 09/05/27, Wu Fengguang wrote:
>> >On Wed, May 27, 2009 at 10:47:47AM +0800, Hisashi Hifumi wrote:
>> >> 
>> >> At 11:36 09/05/27, Wu Fengguang wrote:
>> >> >On Wed, May 27, 2009 at 10:21:53AM +0800, Hisashi Hifumi wrote:
>> >> >>
>> >> >> At 11:09 09/05/27, Wu Fengguang wrote:
>> >> >> >On Wed, May 27, 2009 at 08:25:04AM +0800, Hisashi Hifumi wrote:
>> >> >> >>
>> >> >> >> At 08:42 09/05/27, Andrew Morton wrote:
>> >> >> >> >On Fri, 22 May 2009 10:33:23 +0800
>> >> >> >> >Wu Fengguang <fengguang.wu <at> intel.com> wrote:
>> >> >> >> >
>> >> >> >> >> > I tested above patch, and I got same performance number.
>> >> >> >> >> > I wonder why if (PageUptodate(page)) check is there...
>> >> >> >> >>
>> >> >> >> >> Thanks!  This is an interesting micro timing behavior that
>> >> >> >> >> demands some research work.  The above check is to confirm if it's
>> >> >> >> >> the PageUptodate() case that makes the difference. So why that case
>> >> >> >> >> happens so frequently so as to impact the performance? Will it also
>> >> >> >> >> happen in NFS?
>> >> >> >> >>
>> >> >> >> >> The problem is readahead IO pipeline is not running smoothly, 
>which is
>> >> >> >> >> undesirable and not well understood for now.
>> >> >> >> >

(Continue reading)

Wu Fengguang | 1 Jun 2009 05:02

Picon

Re: [PATCH] readahead:add blk_run_backing_dev

On Mon, Jun 01, 2009 at 10:51:56AM +0800, Hisashi Hifumi wrote:
> 
> At 11:37 09/06/01, Wu Fengguang wrote:
> >On Wed, May 27, 2009 at 11:06:37AM +0800, Hisashi Hifumi wrote:
> >> 
> >> At 11:57 09/05/27, Wu Fengguang wrote:
> >> >On Wed, May 27, 2009 at 10:47:47AM +0800, Hisashi Hifumi wrote:
> >> >> 
> >> >> At 11:36 09/05/27, Wu Fengguang wrote:
> >> >> >On Wed, May 27, 2009 at 10:21:53AM +0800, Hisashi Hifumi wrote:
> >> >> >>
> >> >> >> At 11:09 09/05/27, Wu Fengguang wrote:
> >> >> >> >On Wed, May 27, 2009 at 08:25:04AM +0800, Hisashi Hifumi wrote:
> >> >> >> >>
> >> >> >> >> At 08:42 09/05/27, Andrew Morton wrote:
> >> >> >> >> >On Fri, 22 May 2009 10:33:23 +0800
> >> >> >> >> >Wu Fengguang <fengguang.wu <at> intel.com> wrote:
> >> >> >> >> >
> >> >> >> >> >> > I tested above patch, and I got same performance number.
> >> >> >> >> >> > I wonder why if (PageUptodate(page)) check is there...
> >> >> >> >> >>
> >> >> >> >> >> Thanks!  This is an interesting micro timing behavior that
> >> >> >> >> >> demands some research work.  The above check is to confirm if it's
> >> >> >> >> >> the PageUptodate() case that makes the difference. So why that case
> >> >> >> >> >> happens so frequently so as to impact the performance? Will it also
> >> >> >> >> >> happen in NFS?
> >> >> >> >> >>
> >> >> >> >> >> The problem is readahead IO pipeline is not running smoothly, 
> >which is
> >> >> >> >> >> undesirable and not well understood for now.

(Continue reading)

KOSAKI Motohiro | 1 Jun 2009 05:06

Re: [PATCH] readahead:add blk_run_backing_dev

> > >> >I mean, you should get >300MB/s throughput with 7 disks, and you
> > >> >should seek ways to achieve that before testing out this patch 
> > >> 
> > >> Throughput number of storage array is very from one product to another.
> > >> On my hardware environment I think this number is valid and
> > >> my patch is effective.
> > >
> > >What's your readahead size? Is it large enough to cover the stripe width?
> > 
> > Do you mean strage's readahead size?
> 
> What's strage? I mean if your RAID's block device file is /dev/sda, then

I guess it's typo 
but I recommend he use sane test environment...

> 
>         blockdev --getra /dev/sda
> 
> will tell its readahead size in unit of 512 bytes.
> 
> Thanks,
> Fengguang
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Hisashi Hifumi | 1 Jun 2009 05:07

Picon

Re: [PATCH] readahead:add blk_run_backing_dev


At 12:02 09/06/01, Wu Fengguang wrote:
>On Mon, Jun 01, 2009 at 10:51:56AM +0800, Hisashi Hifumi wrote:
>> 
>> At 11:37 09/06/01, Wu Fengguang wrote:
>> >On Wed, May 27, 2009 at 11:06:37AM +0800, Hisashi Hifumi wrote:
>> >> 
>> >> At 11:57 09/05/27, Wu Fengguang wrote:
>> >> >On Wed, May 27, 2009 at 10:47:47AM +0800, Hisashi Hifumi wrote:
>> >> >> 
>> >> >> At 11:36 09/05/27, Wu Fengguang wrote:
>> >> >> >On Wed, May 27, 2009 at 10:21:53AM +0800, Hisashi Hifumi wrote:
>> >> >> >>
>> >> >> >> At 11:09 09/05/27, Wu Fengguang wrote:
>> >> >> >> >On Wed, May 27, 2009 at 08:25:04AM +0800, Hisashi Hifumi wrote:
>> >> >> >> >>
>> >> >> >> >> At 08:42 09/05/27, Andrew Morton wrote:
>> >> >> >> >> >On Fri, 22 May 2009 10:33:23 +0800
>> >> >> >> >> >Wu Fengguang <fengguang.wu <at> intel.com> wrote:
>> >> >> >> >> >
>> >> >> >> >> >> > I tested above patch, and I got same performance number.
>> >> >> >> >> >> > I wonder why if (PageUptodate(page)) check is there...
>> >> >> >> >> >>
>> >> >> >> >> >> Thanks!  This is an interesting micro timing behavior that
>> >> >> >> >> >> demands some research work.  The above check is to confirm 
>if it's
>> >> >> >> >> >> the PageUptodate() case that makes the difference. So why 
>that case
>> >> >> >> >> >> happens so frequently so as to impact the performance? 
>Will it also

(Continue reading)

Wu Fengguang | 1 Jun 2009 06:30

Picon

Re: [PATCH] readahead:add blk_run_backing_dev

On Mon, Jun 01, 2009 at 11:07:42AM +0800, Hisashi Hifumi wrote:
> 
> At 12:02 09/06/01, Wu Fengguang wrote:
> >On Mon, Jun 01, 2009 at 10:51:56AM +0800, Hisashi Hifumi wrote:
> >> 
> >> At 11:37 09/06/01, Wu Fengguang wrote:
> >> >On Wed, May 27, 2009 at 11:06:37AM +0800, Hisashi Hifumi wrote:
> >> >> 
> >> >> At 11:57 09/05/27, Wu Fengguang wrote:
> >> >> >On Wed, May 27, 2009 at 10:47:47AM +0800, Hisashi Hifumi wrote:
> >> >> >> 
> >> >> >> At 11:36 09/05/27, Wu Fengguang wrote:
> >> >> >> >On Wed, May 27, 2009 at 10:21:53AM +0800, Hisashi Hifumi wrote:
> >> >> >> >>
> >> >> >> >> At 11:09 09/05/27, Wu Fengguang wrote:
> >> >> >> >> >On Wed, May 27, 2009 at 08:25:04AM +0800, Hisashi Hifumi wrote:
> >> >> >> >> >>
> >> >> >> >> >> At 08:42 09/05/27, Andrew Morton wrote:
> >> >> >> >> >> >On Fri, 22 May 2009 10:33:23 +0800
> >> >> >> >> >> >Wu Fengguang <fengguang.wu <at> intel.com> wrote:
> >> >> >> >> >> >
> >> >> >> >> >> >> > I tested above patch, and I got same performance number.
> >> >> >> >> >> >> > I wonder why if (PageUptodate(page)) check is there...
> >> >> >> >> >> >>
> >> >> >> >> >> >> Thanks!  This is an interesting micro timing behavior that
> >> >> >> >> >> >> demands some research work.  The above check is to confirm 
> >if it's
> >> >> >> >> >> >> the PageUptodate() case that makes the difference. So why 
> >that case
> >> >> >> >> >> >> happens so frequently so as to impact the performance?

(Continue reading)

Daisuke Nishimura | 1 Jun 2009 06:25

Picon

Picon

Re: [RFC] Low overhead patches for the memory cgroup controller (v2)

I'm sorry for my very late reply.

I've been working on the stale swap cache problem for a long time as you know :)

On Sun, 17 May 2009 12:15:43 +0800, Balbir Singh <balbir <at> linux.vnet.ibm.com> wrote:
> * KAMEZAWA Hiroyuki <kamezawa.hiroyu <at> jp.fujitsu.com> [2009-05-16 02:45:03]:
> 
> > I think set/clear flag here adds race condtion....because pc->flags is
> > modfied by
> >   pc->flags = pcg_dafault_flags[ctype] in commit_charge()
> > you have to modify above lines to be
> > 
> >   SetPageCgroupCache(pc) or some..
> >   ...
> >   SetPageCgroupUsed(pc)
> > 
> > Then, you can use set_bit() without lock_page_cgroup().
> > (Currently, pc->flags is modified only under lock_page_cgroup(), so,
> >  non atomic code is used.)
> >
> 
> Here is the next version of the patch
> 
> 
> Feature: Remove the overhead associated with the root cgroup
> 
> From: Balbir Singh <balbir <at> linux.vnet.ibm.com>
> 
> This patch changes the memory cgroup and removes the overhead associated
> with accounting all pages in the root cgroup. As a side-effect, we can

(Continue reading)

Group

gmane.linux.kernel.mm.

Search Archive

Page

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

Articles in period: 1574

June 2009

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 0/5] ACPI / scan / memhotplug: ACPI hotplug rework followup cha (19 May 2013)
[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)

Archives

895	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