KSWAPD Algorithm

KSWAPD Algorithm

[wassim dagash]

Hi All,
Description:
I countered a weird problem with kswapd:
it runs in some infinite loop trying to swap until order 10 of zone
highmem is OK, While zone higmem (as I understand) has nothing to do
with contiguous physical memory (cause there is no 1-1 mapping) which
means kswapd will continue to try to balance order 10 of zone highmem
forever (or until someone release a very large chunk of highmem).
Can anyone please explain me the algorithm of kswapd and why it tries
to balance order 10 of zone higmem ?

Details:
I build an instrumented kernel with debug messages in
"zone_watermark_ok" function, and from the code and debug messages I
see that "zone_watermark_ok" returns 0 when kswapd invokes it (through
balance_pgdat) in order to decide if zone highmem is balanced or not,
which lead in some configurations to infinite loop of kswapd ( if no
large chunks of highmem released) . I added a condition to
"balance_pgdat" so it doesn't try to balance order higher than 1 in
zone highmem and this conditon solved the problem, what are the risks
with such solution? isn't it a bug that kswapd is looking for
continuous memory in zone highmem ( as I understand there is no 1-1
mapping in zone highmem which is meaningless in kswapd)?

Regards,
Wassim Dagash.

Re: KSWAPD Algorithm

[Andi Kleen]

"wassim dagash" <wassim.dagash@gmail.com> writes:

> Hi All,
> Description:
> I countered a weird problem with kswapd:
> it runs in some infinite loop trying to swap until order 10 of zone
> highmem is OK, While zone higmem (as I understand) has nothing to do
> with contiguous physical memory (cause there is no 1-1 mapping) which
> means kswapd will continue to try to balance order 10 of zone highmem
> forever (or until someone release a very large chunk of highmem).
> Can anyone please explain me the algorithm of kswapd and why it tries
> to balance order 10 of zone higmem ?

hugetlbfs requires large continuous mappings even in highmem
to map 2MB pages or similar to user space.
However order 10 seems pretty high, normally that's only order 8
on a i386 system.

-Andi

-- 
ak@linux.intel.com

Re: KSWAPD Algorithm

[KAMEZAWA Hiroyuki]

On Wed, 03 Dec 2008 15:51:11 +0100
Andi Kleen <andi@firstfloor.org> wrote:

> "wassim dagash" <wassim.dagash@gmail.com> writes:
> 
> > Hi All,
> > Description:
> > I countered a weird problem with kswapd:
> > it runs in some infinite loop trying to swap until order 10 of zone
> > highmem is OK, While zone higmem (as I understand) has nothing to do
> > with contiguous physical memory (cause there is no 1-1 mapping) which
> > means kswapd will continue to try to balance order 10 of zone highmem
> > forever (or until someone release a very large chunk of highmem).
> > Can anyone please explain me the algorithm of kswapd and why it tries
> > to balance order 10 of zone higmem ?
> 
> hugetlbfs requires large continuous mappings even in highmem
> to map 2MB pages or similar to user space.
> However order 10 seems pretty high, normally that's only order 8
> on a i386 system.
> 

Reading Kosaki's explanation, it seems

  - order-10 allocation occurs at ZONE_NORMAL.

  - kswapd is kicked with order=10.
	wakeup_kswaps(zone, 10) -> pgdat->kswapd_max_order = 10.
  
  - kswapd(balance_pgdat()) does 
	if (!zone_watermark_ok(zone, order, zone->pages_high, end_zone, 0))
			all_zones_ok = 0;
    And this "zone" is all zone, i.e. DMA, NORMAL, HIGHMEM.

    Then, loop again,

	if (!all_zones_ok) {
		cond_resched();

		try_to_freeze();

		goto loop_again;
	}

Maybe...

-Kame