[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87hce4uya8.fsf@basil.nowhere.org>
Date: Mon, 14 Apr 2008 19:44:15 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Denys Vlasenko <vda.linux@...glemail.com>
Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: Does process need to have a kernel-side stack all the time?
Denys Vlasenko <vda.linux@...glemail.com> writes:
> A lot of effort went into minimizing of stack usage.
> If I understand it correctly, one of the reasons for this
> was to be efficient and not have lots of pages
> used for stacks when we have a lot of threads
> (tens of thousands).
Actually the real reason the 4K stacks were introduced IIRC was that
the VM is not very good at allocation of order > 0 pages and that only
using order 0 and not order 1 in normal operation prevented some stalls.
This rationale also goes back to 2.4 (especially some of the early 2.4
VMs were not very good) and the 2.6 VM is generally better and on
x86-64 I don't see much evidence that these stalls are a big problem
(but then x86-64 also has more lowmem).
Note that your proposal doesn't change this at all.
I personally think 4K stacks are a bad idea because code
is always getting more complex and having more stack is
a very useful safety margin.
> A random thought occurred to me: in a system with so many
> threads most of them are not executing anyway, even on
> that gigantic Altix machines. Do they all need to have
> kernel stack, all the time? I mean: the process which
> is running in user space is not using kernel stack at all.
> Process which is not running on a CPU right now
> is not using it either.
Actually processes that sleep do use the stack.
Take a look at Sysrq-t output some time. Pretty much
all sleepers have some context.
Only processes currently running in user land do not use
the kernel stack, but there are very little of them
(never more than you have CPUs)
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists