From: Matthew Wilcox <matthew@wil.cx>
To: kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] Documentation: Explain 4K stacks in slightly more detail.
Date: Fri, 25 Apr 2008 20:11:13 +0000 [thread overview]
Message-ID: <20080425201113.GN14990@parisc-linux.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0804251549050.20250@localhost.localdomain>
[patch mangled so I can comment on each sentence]
On Fri, Apr 25, 2008 at 03:50:34PM -0400, Robert P. J. Day wrote:
> - If you say Y here the kernel will use a 4Kb stacksize for the
> - kernel stack attached to each process/thread.
> + If you say Y here, this will redefine the value of THREAD_SIZE
> + from 8K to 4K and subsequently use a 4K kernel stack for each
> + process/thread.
This is a terrible change. The user doesn't care what THREAD_SIZE is or
means within the kernel. The programmer can grep for the CONFIG option
to see what changed. Nack this portion.
> - This facilitates
> - running more threads on a system and also reduces the pressure
> - on the VM subsystem for higher order allocations.
> + This facilitates running more threads on a
> + system and also reduces the pressure on the VM subsystem for
> + higher-order allocations (that is, trying to find two consecutive
> + 4K pages rather than just one for each per-process kernel stack).
Good that you've explained the jargon. But I'd rather see it removed.
How does this read?
This facilitates running more threads on your system and means
the VM system has to work less hard to find two consecutive 4k
pages.
> - This option
> - will also use IRQ stacks to compensate for the reduced stackspace.
> + To compensate for the smaller per-process stack, interrupts will
> + now be given their own 4K per-cpu stacks.
Again, your text is an improvement. How about this though:
To partially compensate for the smaller stack size, interrupts
will run on their own stack, reducing the chances of a stack
overflow.
> + For more discussion,
> + see http://lwn.net/Articles/150580/. Also, see the implementation
> + in the source file arch/x86/kernel/irq_32.c.
I'm not keen on this sentence.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2008-04-25 20:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-25 19:50 [PATCH] Documentation: Explain 4K stacks in slightly more detail Robert P. J. Day
2008-04-25 20:11 ` Matthew Wilcox [this message]
2008-04-25 20:29 ` [PATCH] Documentation: Explain 4K stacks in slightly more Robert P. J. Day
2008-04-25 20:41 ` [PATCH] Documentation: Explain 4K stacks in slightly more detail Matthew Wilcox
2008-04-25 21:27 ` [PATCH] Documentation: Explain 4K stacks in slightly more Robert P. J. Day
2008-04-26 12:20 ` [PATCH] Documentation: Explain 4K stacks in slightly more detail Nick Andrew
2008-04-26 12:23 ` [PATCH] Documentation: Explain 4K stacks in slightly more Robert P. J. Day
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080425201113.GN14990@parisc-linux.org \
--to=matthew@wil.cx \
--cc=kernel-janitors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.