2002-03-01 17:39:11

by Dave McCracken

[permalink] [raw]
Subject: [PATCH 2.4.19-pre2] Make max_threads be based on normal zone size


The max_threads config parameter (used to determine how many tasks to
allow) is currently calculated based on the total amount of physical memory
in the machine. This is wrong, since the real limiting factor is the
amount of memory in the normal zone.

This patch fixes the initialization of max_threads by allowing an
architecture to specify how much memory is in the normal zone, and using
that value to initialize max_threads.

My apologies for sending it as an attachment, but I don't trust my mail
client not to screw up an inline patch.

Dave McCracken

======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
[email protected] T/L 678-3059


Attachments:
(No filename) (775.00 B)
memsize-2.4.19-pre2.diff (2.25 kB)
Download all attachments

2002-03-01 18:15:39

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH 2.4.19-pre2] Make max_threads be based on normal zone size

Dave McCracken <[email protected]> writes:

> The max_threads config parameter (used to determine how many tasks to
> allow) is currently calculated based on the total amount of physical memory
> in the machine. This is wrong, since the real limiting factor is the
> amount of memory in the normal zone.
>
> This patch fixes the initialization of max_threads by allowing an
> architecture to specify how much memory is in the normal zone, and using
> that value to initialize max_threads.

There are lots of other functions with the same problem (like all the
hash table sizing and others). Perhaps these should be fixed too?

-Andi

2002-03-01 18:19:44

by Dave McCracken

[permalink] [raw]
Subject: Re: [PATCH 2.4.19-pre2] Make max_threads be based on normal zone size


--On Friday, March 01, 2002 19:14:41 +0100 Andi Kleen <[email protected]> wrote:

> There are lots of other functions with the same problem (like all the
> hash table sizing and others). Perhaps these should be fixed too?

I coded the patch in a fashion that makes both total physical memory and
mapped physical memory size available, specifically so other people could
change places that might also have the same problem. I guessed there might
be some.

Dave McCracken

======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
[email protected] T/L 678-3059