Re: [PATCH] Re: simple FS application that hangs 2.4-test5, mem mgmtproblem or FS buffer cache mgmt problem?

From: Roger Larsson (
Date: Wed Aug 02 2000 - 19:00:09 EST

Rik van Riel wrote:
> On Thu, 3 Aug 2000, Roger Larsson wrote:
> > One thing to remember.
> > Working limits are lowered due to not running kswapd until ALL
> > zones have zone_wake_kswapd.
> Which is OK, since at that point we still have the
> difference between pages_low and pages_min to go
> before allocations get _throttled_.
> NOTE: this should only affect system *performance*,
> never stability!
> > Maybe limits need to be refined (linux/mm/page_alloc.c)
> ^^^^^
> This word should tip you off that the patch below really
> doesn't make much sense...
> Rule of thumb: if you can't explain _why_ it makes sense,
> it probably doesn't.

It does make _some_ sense - on most normal system you get about
the same actual limits for all zones. And DMA memory have
some cases where it is more important to have more of it.

> > This has lead me to the conclusion that kswapd can't be made
> > to handle the most intensive loads. It is easy force yourself
> > into a situation where both zone_wake_kswapd and low_on_memory
> > are set for all zones...
> I guess that means that either kswapd is going back to sleep
> without getting any work done, or kswapd isn't scheduled in
> when it should be.

A process might allocate a lot of memory in one time slice...
> Changing the limits will mean it's _harder_ to get into the
> same situation, but it really doesn't do anything to actually
> *fix* the problem. The problem being that kswapd doesn't get
> run or doesn't free pages as fast as it should when we try to
> wake it up.

Correct, but since we have less memory to play with...
A failure of try_to_free_pages (not kswapd) with this scenario:

- freeing some pages (FREE_COUNT - 1)
- sleeping (due to need_reschedule or waiting for buffer)
   - other process uses up available pages
- trying to free remaining (1) but failing
- returning with success...

the need_reschedule case can be improved with this:
(always retrying the full amount after schedule sleep,
 probably a loop on failures in try_to_free_pages as well...)

(in vmscan.c function do_try_to_free_pages)
                if (gfp_mask & __GFP_WAIT &&
                    current->need_resched) {
                        /* time has passed - pressure too? */
                        if (!memory_pressure())
                                goto done;
                        /* pages freed by me might be gone... */
                        count = FREE_COUNT;

> (or kswapd going to sleep too soon? IMHO it should go to sleep
> only when *all* zones have zone->free_pages > zone->pages_low
> and at least one zone has zone->zone_wake_kswapd cleared)

Think so too - my original patch did this, in a complicated way...
this should be an easier way. (also in vmscan.c (not tested))

static inline int keep_kswapd_awake(void)
        pg_data_t *pgdat;

        if (memory_pressure())
                return 1;

        pgdat = pgdat_list;
        do {
                int i;
                for(i = 0; i < MAX_NR_ZONES; i++) {

I will prepare (and test) proper patches tomorrow...


Home page:

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:10 EST