On Mon, 31 Jan 2005, Hugh Dickins said:
> On Mon, 31 Jan 2005, Nix wrote:
>> (2.6.10 seems to *run* perfectly well on that box, for what it's worth;
>> unless this is a symptom of some underlying dark and terrible failure,
>> it looks like a not-very-important cosmetic bug.)
> 
> A lot of the time you're right and it is just cosmetic.  But if memory
> gets tight and it should be using swap, it mistakenly fails to do so,
> so you may end up getting OOM-killed.  Patch below is a temporary hack
> workaround against that.

Odd: this machine seems to be using swap, albeit not very much (and I've
got the swap priorities upside down, as well; whoops, that's probably
been harming performance for, well, years):

Filename                                Type            Size    Used    Priority
/dev/sda2                               partition       523016  0       1
/dev/sda4                               partition       511232  57648   2
/dev/sdb2                               partition       523016  0       1

Is the problem that the higher-priority kicking out to swap which should
happen when memory is tight, won't?

>                           The Mapped count also affects when dirty file
> writeback kicks in, but the effect there appears to be less serious.

... since it kicks in eventually anyway.

> More worrying is, what else might sparc64 gcc-3.4 be getting wrong?

That's a question that's very hard to answer until we know the cause of
this failure and can fix it: then we can go through the RTL or assembler
dumps of a kernel compilation and comb more potential problems out
(or not: it's probably a long and thankless task).

I'll build rmap.c with GCC-3.3 later tonight (if I can find a copy on my
old backups), compare the generated code, and see if anything leaps out
at me.

> --- 2.6.10/mm/vmscan.c        2004-12-24 21:36:18.000000000 +0000
> +++ linux/mm/vmscan.c 2005-01-31 12:44:56.006629152 +0000
> @@ -690,6 +690,8 @@ refill_inactive_zone(struct zone *zone, 
>        * is mapped.
>        */
>       mapped_ratio = (sc->nr_mapped * 100) / total_memory;
> +     if (mapped_ratio < 0)
> +             mapped_ratio = 78;
>  
>       /*
>        * Now decide how much we really want to unmap some pages.  The mapped

`78'? A hack indeed! :)

-- 
`Blish is clearly in love with language. Unfortunately,
 language dislikes him intensely.' --- Russ Allbery
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to