All of lore.kernel.org
 help / color / mirror / Atom feed
* Use ZVC counters to establish exact size of dirtyable pages
@ 2007-02-12 18:16 Christoph Lameter
  2007-02-13  8:04 ` Andrew Morton
  0 siblings, 1 reply; 11+ messages in thread
From: Christoph Lameter @ 2007-02-12 18:16 UTC (permalink / raw)
  To: akpm; +Cc: linux-mm

We can use the global ZVC counters to establish the exact size of the LRU
and the free pages allowing a more accurate determination of the dirty
ratio.

This patch will fix the broken ratio calculations if large amounts of
memory are allocated to huge pags or other consumers that do not put the
pages on to the LRU.

Notes:
- I did not add NR_SLAB_RECLAIMABLE to the calculation of the
  dirtyable pages. Those may be reclaimable but they are at this
  point not dirtyable. If NR_SLAB_RECLAIMABLE would be considered
  then a huge number of reclaimable slab pages could stop writeback
  from occurring.

- This patch used to be in mm as the last one in a series of patches.
  It was removed when Linus updated the treatment of highmem because
  there was a conflict. I updated the patch to follow Linus' approach.
  This patch is neede to fulfill the claims made in the beginning of the
  patchset that is now in Linus' tree.

- I added an optimized path for i386 NUMA since the zone
  layout allows determination of the non HIGHMEM pages
  by adding up lowmem zones on node 0.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>

Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c	2007-02-12 09:15:22.000000000 -0800
+++ linux-2.6/mm/page-writeback.c	2007-02-12 10:06:15.000000000 -0800
@@ -119,6 +119,58 @@ static void background_writeout(unsigned
  * We make sure that the background writeout level is below the adjusted
  * clamping level.
  */
+
+static unsigned long determine_dirtyable_memory(void)
+{
+	unsigned long x;
+
+#ifndef CONFIG_HIGHMEM
+	x = global_page_state(NR_FREE_PAGES)
+		+ global_page_state(NR_INACTIVE)
+		+ global_page_state(NR_ACTIVE);
+#else
+	/*
+	 * We always exclude high memory from our count
+	 */
+#if defined(CONFIG_NUMA) && defined(CONFIG_X86_32)
+	/*
+	 * i386 32 bit NUMA configurations have all non HIGHMEM zones on
+	 * node 0. So its easier to just add up the lowmemt zones on node 0.
+	 */
+	struct zone * z;
+
+	x = 0;
+	for (z = NODE_DATA(0)->node_zones;
+			z < NODE_DATA(0)->node_zones + ZONE_HIGHMEM;
+			z++)
+		x = zone_page_state(z, NR_FREE_PAGES)
+			+ zone_page_state(z, NR_INACTIVE)
+			+ zone_page_state(z, NR_ACTIVE);
+
+#else
+	/*
+	 * Just subtract the HIGHMEM zones.
+	 */
+	int node;
+
+	x = global_page_state(NR_FREE_PAGES)
+		+ global_page_state(NR_INACTIVE)
+		+ global_page_state(NR_ACTIVE);
+
+	for_each_online_node(node) {
+		struct zone *z =
+			&NODE_DATA(node)->node_zones[ZONE_HIGHMEM];
+
+		x -= zone_page_state(z, NR_FREE_PAGES)
+			+ zone_page_state(z, NR_INACTIVE)
+			+ zone_page_state(z, NR_ACTIVE);
+	}
+
+#endif
+#endif /* CONFIG_HIGHMEM */
+	return x;
+}
+
 static void
 get_dirty_limits(long *pbackground, long *pdirty,
 					struct address_space *mapping)
@@ -128,17 +180,9 @@ get_dirty_limits(long *pbackground, long
 	int unmapped_ratio;
 	long background;
 	long dirty;
-	unsigned long available_memory = vm_total_pages;
+	unsigned long available_memory = determine_dirtyable_memory();
 	struct task_struct *tsk;
 
-#ifdef CONFIG_HIGHMEM
-	/*
-	 * We always exclude high memory from our count.
-	 */
-	available_memory -= totalhigh_pages;
-#endif
-
-
 	unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) +
 				global_page_state(NR_ANON_PAGES)) * 100) /
 					vm_total_pages;

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-12 18:16 Use ZVC counters to establish exact size of dirtyable pages Christoph Lameter
@ 2007-02-13  8:04 ` Andrew Morton
  2007-02-13 17:43   ` Christoph Lameter
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Morton @ 2007-02-13  8:04 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm

On Mon, 12 Feb 2007 10:16:23 -0800 (PST) Christoph Lameter <clameter@sgi.com> wrote:

> +static unsigned long determine_dirtyable_memory(void)
> +{
> +	unsigned long x;
> +
> +#ifndef CONFIG_HIGHMEM
> +	x = global_page_state(NR_FREE_PAGES)
> +		+ global_page_state(NR_INACTIVE)
> +		+ global_page_state(NR_ACTIVE);
> +#else
> +	/*
> +	 * We always exclude high memory from our count
> +	 */
> +#if defined(CONFIG_NUMA) && defined(CONFIG_X86_32)
> +	/*
> +	 * i386 32 bit NUMA configurations have all non HIGHMEM zones on
> +	 * node 0. So its easier to just add up the lowmemt zones on node 0.
> +	 */
> +	struct zone * z;
> +
> +	x = 0;
> +	for (z = NODE_DATA(0)->node_zones;
> +			z < NODE_DATA(0)->node_zones + ZONE_HIGHMEM;
> +			z++)
> +		x = zone_page_state(z, NR_FREE_PAGES)
> +			+ zone_page_state(z, NR_INACTIVE)
> +			+ zone_page_state(z, NR_ACTIVE);
> +
> +#else
> +	/*
> +	 * Just subtract the HIGHMEM zones.
> +	 */
> +	int node;
> +
> +	x = global_page_state(NR_FREE_PAGES)
> +		+ global_page_state(NR_INACTIVE)
> +		+ global_page_state(NR_ACTIVE);
> +
> +	for_each_online_node(node) {
> +		struct zone *z =
> +			&NODE_DATA(node)->node_zones[ZONE_HIGHMEM];
> +
> +		x -= zone_page_state(z, NR_FREE_PAGES)
> +			+ zone_page_state(z, NR_INACTIVE)
> +			+ zone_page_state(z, NR_ACTIVE);
> +	}
> +
> +#endif
> +#endif /* CONFIG_HIGHMEM */
> +	return x;
> +}

gaaack.

If CONFIG_HIGHMEM=n and CONFIG_NUMA=n, that definition of `node' is going
to come after the calculation of `x' and is going to spit a warning.

And we'll run global_page_state() six times where three would have
sufficed.

Also I think you'll be wanting a += in that first loop.

I believe i386 NUMA is rare as hen's teeth and perhaps we can just forget
about optimising for it.

Wanna have another go at this?  Perhaps split it into separate functions or
something.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-13  8:04 ` Andrew Morton
@ 2007-02-13 17:43   ` Christoph Lameter
  2007-02-13 18:03     ` Andrew Morton
  2007-02-14 22:24     ` Andrew Morton
  0 siblings, 2 replies; 11+ messages in thread
From: Christoph Lameter @ 2007-02-13 17:43 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm

On Tue, 13 Feb 2007, Andrew Morton wrote:

> gaaack.
> 
> If CONFIG_HIGHMEM=n and CONFIG_NUMA=n, that definition of `node' is going
> to come after the calculation of `x' and is going to spit a warning.

Ummm... No. If CONFIG_HIGMEM=n then the definition of node is not going
to be included in the source to be compiled.

> Also I think you'll be wanting a += in that first loop.

Correct. What would I do without you?
 
> I believe i386 NUMA is rare as hen's teeth and perhaps we can just forget
> about optimising for it.

I was just trying to avoid complaints..... I'd be glad to drop the stuff. 
Its going to be much simpler that way.
 
> Wanna have another go at this?  Perhaps split it into separate functions or
> something.

Ok. I split out the highmem stuff which makes determine_dirtyable_memory() 
nice and neat.





We can use the global ZVC counters to establish the exact size of the LRU
and the free pages.  This allows a more accurate determination of the dirty
ratio.

This patch will fix the broken ratio calculations if large amounts of
memory are allocated to huge pags or other consumers that do not put the
pages on to the LRU.

Notes:
- I did not add NR_SLAB_RECLAIMABLE to the calculation of the
  dirtyable pages. Those may be reclaimable but they are at this
  point not dirtyable. If NR_SLAB_RECLAIMABLE would be considered
  then a huge number of reclaimable pages would stop writeback
  from occurring.

- This patch used to be in mm as the last one in a series of patches.
  It was removed when Linus updated the treatment of highmem because
  there was a conflict. I updated the patch to follow Linus' approach.
  This patch is neede to fulfill the claims made in the beginning of the
  patchset that is now in Linus' tree.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>

Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c	2007-02-12 09:15:22.000000000 -0800
+++ linux-2.6/mm/page-writeback.c	2007-02-13 09:40:04.000000000 -0800
@@ -119,6 +119,38 @@ static void background_writeout(unsigned
  * We make sure that the background writeout level is below the adjusted
  * clamping level.
  */
+
+static unsigned long highmem_dirtyable_memory(void)
+{
+#ifdef CONFIG_HIGHMEM
+	int node;
+	unsigned long x = 0;
+
+	for_each_online_node(node) {
+		struct zone *z =
+			&NODE_DATA(node)->node_zones[ZONE_HIGHMEM];
+
+		x += zone_page_state(z, NR_FREE_PAGES)
+			+ zone_page_state(z, NR_INACTIVE)
+			+ zone_page_state(z, NR_ACTIVE);
+	}
+	return x;
+#else
+	return 0;
+#endif
+}
+
+static unsigned long determine_dirtyable_memory(void)
+{
+	unsigned long x;
+
+	x = global_page_state(NR_FREE_PAGES)
+		+ global_page_state(NR_INACTIVE)
+		+ global_page_state(NR_ACTIVE)
+		- highmem_dirtyable_memory();
+	return x;
+}
+
 static void
 get_dirty_limits(long *pbackground, long *pdirty,
 					struct address_space *mapping)
@@ -128,17 +160,9 @@ get_dirty_limits(long *pbackground, long
 	int unmapped_ratio;
 	long background;
 	long dirty;
-	unsigned long available_memory = vm_total_pages;
+	unsigned long available_memory = determine_dirtyable_memory();
 	struct task_struct *tsk;
 
-#ifdef CONFIG_HIGHMEM
-	/*
-	 * We always exclude high memory from our count.
-	 */
-	available_memory -= totalhigh_pages;
-#endif
-
-
 	unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) +
 				global_page_state(NR_ANON_PAGES)) * 100) /
 					vm_total_pages;

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-13 17:43   ` Christoph Lameter
@ 2007-02-13 18:03     ` Andrew Morton
  2007-02-14 22:24     ` Andrew Morton
  1 sibling, 0 replies; 11+ messages in thread
From: Andrew Morton @ 2007-02-13 18:03 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm

> On Tue, 13 Feb 2007 09:43:43 -0800 (PST) Christoph Lameter <clameter@sgi.com> wrote:
> > I believe i386 NUMA is rare as hen's teeth and perhaps we can just forget
> > about optimising for it.
> 
> I was just trying to avoid complaints..... I'd be glad to drop the stuff. 
> Its going to be much simpler that way.

That code used to do a walk across each CPU's global memory counters and
hence was quite expensive.  But it's called infrequently, so things were
OK.  And it is still called infrequently, so I expect we'll still be OK
here.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-13 17:43   ` Christoph Lameter
  2007-02-13 18:03     ` Andrew Morton
@ 2007-02-14 22:24     ` Andrew Morton
  2007-02-14 22:41       ` Christoph Lameter
  1 sibling, 1 reply; 11+ messages in thread
From: Andrew Morton @ 2007-02-14 22:24 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm

On Tue, 13 Feb 2007 09:43:43 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> We can use the global ZVC counters to establish the exact size of the LRU
> and the free pages.  This allows a more accurate determination of the dirty
> ratio.
> 
> This patch will fix the broken ratio calculations if large amounts of
> memory are allocated to huge pags or other consumers that do not put the
> pages on to the LRU.
> 
> Notes:
> - I did not add NR_SLAB_RECLAIMABLE to the calculation of the
>   dirtyable pages. Those may be reclaimable but they are at this
>   point not dirtyable. If NR_SLAB_RECLAIMABLE would be considered
>   then a huge number of reclaimable pages would stop writeback
>   from occurring.
> 
> - This patch used to be in mm as the last one in a series of patches.
>   It was removed when Linus updated the treatment of highmem because
>   there was a conflict. I updated the patch to follow Linus' approach.
>   This patch is neede to fulfill the claims made in the beginning of the
>   patchset that is now in Linus' tree.
> 

Let's get paranoid.

> --- linux-2.6.orig/mm/page-writeback.c	2007-02-12 09:15:22.000000000 -0800
> +++ linux-2.6/mm/page-writeback.c	2007-02-13 09:40:04.000000000 -0800
> @@ -119,6 +119,38 @@ static void background_writeout(unsigned
>   * We make sure that the background writeout level is below the adjusted
>   * clamping level.
>   */
> +
> +static unsigned long highmem_dirtyable_memory(void)
> +{
> +#ifdef CONFIG_HIGHMEM
> +	int node;
> +	unsigned long x = 0;
> +
> +	for_each_online_node(node) {
> +		struct zone *z =
> +			&NODE_DATA(node)->node_zones[ZONE_HIGHMEM];
> +
> +		x += zone_page_state(z, NR_FREE_PAGES)
> +			+ zone_page_state(z, NR_INACTIVE)
> +			+ zone_page_state(z, NR_ACTIVE);
> +	}
> +	return x;
> +#else
> +	return 0;
> +#endif
> +}
> +
> +static unsigned long determine_dirtyable_memory(void)
> +{
> +	unsigned long x;
> +
> +	x = global_page_state(NR_FREE_PAGES)
> +		+ global_page_state(NR_INACTIVE)
> +		+ global_page_state(NR_ACTIVE)
> +		- highmem_dirtyable_memory();
> +	return x;
> +}

Suppose a zone has ten dirty pages.  All the remaining pages in the zone
are off being used for soundcard buffers and networking skbs.

The zone's ten dirty pages are temporarily off the LRU, being processed by
the vm scanner.

So we're now in the state where the zone has more dirty pages than it has
dirtyable memory(!).

This function will return zero.  Which I think we'll happen to handle OK.

But this function can, I think, also return negative (ie: very large)
numbers.  I don't think we handle that right.


>  static void
>  get_dirty_limits(long *pbackground, long *pdirty,
>  					struct address_space *mapping)
> @@ -128,17 +160,9 @@ get_dirty_limits(long *pbackground, long
>  	int unmapped_ratio;
>  	long background;
>  	long dirty;
> -	unsigned long available_memory = vm_total_pages;
> +	unsigned long available_memory = determine_dirtyable_memory();
>  	struct task_struct *tsk;
>  
> -#ifdef CONFIG_HIGHMEM
> -	/*
> -	 * We always exclude high memory from our count.
> -	 */
> -	available_memory -= totalhigh_pages;
> -#endif
> -
> -
>  	unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) +
>  				global_page_state(NR_ANON_PAGES)) * 100) /
>  					vm_total_pages;

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-14 22:24     ` Andrew Morton
@ 2007-02-14 22:41       ` Christoph Lameter
  2007-02-14 22:49         ` Christoph Lameter
  2007-02-14 23:19         ` Andrew Morton
  0 siblings, 2 replies; 11+ messages in thread
From: Christoph Lameter @ 2007-02-14 22:41 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm

On Wed, 14 Feb 2007, Andrew Morton wrote:

> Suppose a zone has ten dirty pages.  All the remaining pages in the zone
> are off being used for soundcard buffers and networking skbs.

Thats a pretty artificial situation.There is a min_free_kbytes that 
should give us some safety there. Only GFP_ATOMIC could get us there.

> This function will return zero.  Which I think we'll happen to handle OK.

One would expect the function to return 10. The 10 pages are on the LRU.
If we really have zero dirtyable pages then we will get a division by 
zero problem.

> But this function can, I think, also return negative (ie: very large)
> numbers.  I don't think we handle that right.

How would that occur? The only way that I could think this would happen is 
if for some strange reason the highmem counts are bigger than the total 
counts.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-14 22:41       ` Christoph Lameter
@ 2007-02-14 22:49         ` Christoph Lameter
  2007-02-14 23:19         ` Andrew Morton
  1 sibling, 0 replies; 11+ messages in thread
From: Christoph Lameter @ 2007-02-14 22:49 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm

On Wed, 14 Feb 2007, Christoph Lameter wrote:

> > This function will return zero.  Which I think we'll happen to handle OK.
> 
> One would expect the function to return 10. The 10 pages are on the LRU.
> If we really have zero dirtyable pages then we will get a division by 
> zero problem.

Well we do not have the division by zero problem due to this 
expression that really should also use available_memory

       unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) +
                                global_page_state(NR_ANON_PAGES)) * 100) /
                                        vm_total_pages;

If we would change the basis here too (which is probably a good thing to 
do) then we may have the division by zero issue.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-14 22:41       ` Christoph Lameter
  2007-02-14 22:49         ` Christoph Lameter
@ 2007-02-14 23:19         ` Andrew Morton
  2007-02-14 23:35           ` Christoph Lameter
  1 sibling, 1 reply; 11+ messages in thread
From: Andrew Morton @ 2007-02-14 23:19 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm

On Wed, 14 Feb 2007 14:41:57 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Wed, 14 Feb 2007, Andrew Morton wrote:
> 
> > Suppose a zone has ten dirty pages.  All the remaining pages in the zone
> > are off being used for soundcard buffers and networking skbs.
> 
> Thats a pretty artificial situation.

We hit weird situations in the VM all the time.  There have been
unbelieveably improbable things which someone manages to hit regularly.

> There is a min_free_kbytes that 
> should give us some safety there. Only GFP_ATOMIC could get us there.

network rx happens.  A nice pingflood will chew the page reserves.  e1000
has insanely huge queues.

> > This function will return zero.  Which I think we'll happen to handle OK.
> 
> One would expect the function to return 10. The 10 pages are on the LRU.
> If we really have zero dirtyable pages then we will get a division by 
> zero problem.

The vm scanner does temporarily take these pages off the lru and will
temporarily adjust NR_INACTIVE or NR_ACTIVE to account for this.

> > But this function can, I think, also return negative (ie: very large)
> > numbers.  I don't think we handle that right.
> 
> How would that occur? The only way that I could think this would happen is 
> if for some strange reason the highmem counts are bigger than the total 
> counts.

Dunno, maybe it can't happen.  But those counters are approximate and
perhaps there are edge cases which occur when differences between them are
calculated and most of the pages are not free and not on the LRU.

It all needs careful thought.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-14 23:19         ` Andrew Morton
@ 2007-02-14 23:35           ` Christoph Lameter
  2007-02-14 23:44             ` Andrew Morton
  0 siblings, 1 reply; 11+ messages in thread
From: Christoph Lameter @ 2007-02-14 23:35 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm

On Wed, 14 Feb 2007, Andrew Morton wrote:

> > > But this function can, I think, also return negative (ie: very large)
> > > numbers.  I don't think we handle that right.
> > 
> > How would that occur? The only way that I could think this would happen is 
> > if for some strange reason the highmem counts are bigger than the total 
> > counts.
> 
> Dunno, maybe it can't happen.  But those counters are approximate and
> perhaps there are edge cases which occur when differences between them are
> calculated and most of the pages are not free and not on the LRU.
> 
> It all needs careful thought.

That would require a deferral of counters greater than the size of low 
memory. And this is bound highmem so we are talking about 32 bit systems 
that are pretty limited in their number of processors and storage.

The maximum deferral of a counter is 2 * stat_threshhold * nr_cpus. The 
max that I know about on i386 are 64GB systems. The stat threshold for 
zones with a size <128MB is 10 but we have a range from -threashold .. 
+threashold. So for 8 processors a counter can be deferred at most for 8 * 
2 * 10 * 4 kbytes = 640 kbytes. Assume that all 3 counters are off the max 
then we reach 1920 kbytes. Lets say the highmem counters are also off by 
the max then we reach ~ 4 mbytes. This is still far less than the size of 
low memory.

One could now think that the LRU size could get to less than 4 mbytes 
in lowmem and then we would have a problem. But would such a system still be 
functional?

If you want to be safe we can make sure that the number returned is > 0.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-14 23:35           ` Christoph Lameter
@ 2007-02-14 23:44             ` Andrew Morton
  2007-02-15  0:00               ` Christoph Lameter
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Morton @ 2007-02-14 23:44 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm

On Wed, 14 Feb 2007 15:35:59 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> If you want to be safe we can make sure that the number returned is > 0.

Yes, something like that (with a suitable comment) sounds like the suitable way
to avoid these problems.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Use ZVC counters to establish exact size of dirtyable pages
  2007-02-14 23:44             ` Andrew Morton
@ 2007-02-15  0:00               ` Christoph Lameter
  0 siblings, 0 replies; 11+ messages in thread
From: Christoph Lameter @ 2007-02-15  0:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm

On Wed, 14 Feb 2007, Andrew Morton wrote:

> On Wed, 14 Feb 2007 15:35:59 -0800 (PST)
> Christoph Lameter <clameter@sgi.com> wrote:
> 
> > If you want to be safe we can make sure that the number returned is > 0.
> 
> Yes, something like that (with a suitable comment) sounds like the suitable way
> to avoid these problems.



Insure that dirtyable memory calculation always returns positive number

In order to avoid division by zero and strange results we insure that
the memory calculation of dirtyable memory always returns at least 1.

We need to make sure that highmem_dirtyable_memory() never returns a number
larger than the total dirtyable memory. Counter deferrals and strange VM
situations with unimagiably small lowmem may make the count go negative.

Also base the calculation of the mapped_ratio on the amount of dirtyable
memory.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c	2007-02-14 15:58:42.000000000 -0800
+++ linux-2.6/mm/page-writeback.c	2007-02-14 15:58:45.000000000 -0800
@@ -120,7 +120,7 @@ static void background_writeout(unsigned
  * clamping level.
  */
 
-static unsigned long highmem_dirtyable_memory(void)
+static unsigned long highmem_dirtyable_memory(unsigned long total)
 {
 #ifdef CONFIG_HIGHMEM
 	int node;
@@ -134,7 +134,13 @@ static unsigned long highmem_dirtyable_m
 			+ zone_page_state(z, NR_INACTIVE)
 			+ zone_page_state(z, NR_ACTIVE);
 	}
-	return x;
+	/*
+	 * Make sure that the number of highmem pages is never larger
+	 * than the number of the total dirtyable memory. This can only
+	 * occur in very strange VM situations but we want to make sure
+	 * that this does not occur.
+	 */
+	return min(x, total);
 #else
 	return 0;
 #endif
@@ -146,9 +152,9 @@ static unsigned long determine_dirtyable
 
 	x = global_page_state(NR_FREE_PAGES)
 		+ global_page_state(NR_INACTIVE)
-		+ global_page_state(NR_ACTIVE)
-		- highmem_dirtyable_memory();
-	return x;
+		+ global_page_state(NR_ACTIVE);
+	x -= highmem_dirtyable_memory(x);
+	return x + 1;	/* Insure that we never return 0 */
 }
 
 static void
@@ -165,7 +171,7 @@ get_dirty_limits(long *pbackground, long
 
 	unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) +
 				global_page_state(NR_ANON_PAGES)) * 100) /
-					vm_total_pages;
+					available_memory;
 
 	dirty_ratio = vm_dirty_ratio;
 	if (dirty_ratio > unmapped_ratio / 2)
 

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-02-15  0:00 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-12 18:16 Use ZVC counters to establish exact size of dirtyable pages Christoph Lameter
2007-02-13  8:04 ` Andrew Morton
2007-02-13 17:43   ` Christoph Lameter
2007-02-13 18:03     ` Andrew Morton
2007-02-14 22:24     ` Andrew Morton
2007-02-14 22:41       ` Christoph Lameter
2007-02-14 22:49         ` Christoph Lameter
2007-02-14 23:19         ` Andrew Morton
2007-02-14 23:35           ` Christoph Lameter
2007-02-14 23:44             ` Andrew Morton
2007-02-15  0:00               ` Christoph Lameter

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.