[PATCH] Documentation: Explain 4K stacks in slightly more detail.

[PATCH] Documentation: Explain 4K stacks in slightly more detail.

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

---

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 610aaec..e40d8d4 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -109,11 +109,17 @@ config 4KSTACKS
 	depends on X86_32
 	default y
 	help
-	  If you say Y here the kernel will use a 4Kb stacksize for the
-	  kernel stack attached to each process/thread. This facilitates
-	  running more threads on a system and also reduces the pressure
-	  on the VM subsystem for higher order allocations. This option
-	  will also use IRQ stacks to compensate for the reduced stackspace.
+	  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 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).
+
+	  To compensate for the smaller per-process stack, interrupts will
+	  now be given their own 4K per-cpu stacks.  For more discussion,
+	  see http://lwn.net/Articles/150580/.  Also, see the implementation
+	  in the source file arch/x86/kernel/irq_32.c.

 config X86_FIND_SMP_CONFIG
 	def_bool y

====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
====================================

Re: [PATCH] Documentation: Explain 4K stacks in slightly more detail.

[Matthew Wilcox]

[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."

Re: [PATCH] Documentation: Explain 4K stacks in slightly more

[Robert P. J. Day]

On Fri, 25 Apr 2008, Matthew Wilcox wrote:

> [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.

i thought about that, and the only reason i mentioned it is that
the consequences of selecting 4K stacks is not at all obvious.  i
figured that, if someone was going to try something that tricky,
he/she might want to understand what was happening under the hood.
but i'm happy to take it out.

> > -       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.

that sounds reasonable.  i can find some middle ground between the
two.

> > -	  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.

i would want to keep the explanation that there is going to an
interrupt stack *per CPU*.  that's not obvious from your text.

> > +	  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.

i can leave out the reference to the source file, but i still think a
pointer to a discussion of the feature would be useful.

rday
--

====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
====================================

Re: [PATCH] Documentation: Explain 4K stacks in slightly more detail.

[Matthew Wilcox]

On Fri, Apr 25, 2008 at 04:29:01PM -0400, Robert P. J. Day wrote:
> On Fri, 25 Apr 2008, Matthew Wilcox wrote:
> > [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.
> 
> i thought about that, and the only reason i mentioned it is that
> the consequences of selecting 4K stacks is not at all obvious.  i
> figured that, if someone was going to try something that tricky,
> he/she might want to understand what was happening under the hood.
> but i'm happy to take it out.

I just ran a grep for 4KSTACKS ... this text appears to have been
duplicated into three other architectures, so should be updated on all
of them together.  Except for the bit about the interrupt stacks; as far
as I can tell, they don't do that.

> > > -	  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.
> 
> i would want to keep the explanation that there is going to an
> interrupt stack *per CPU*.  that's not obvious from your text.

Why does the user care?  It's important to you and me, but someone who's
configuring their kernel needs to be told enough information to make an
informed decision about an option.  There's already a lot of complex
information here, let's not distract them with an implementation detail.

> > > +	  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.
> 
> i can leave out the reference to the source file, but i still think a
> pointer to a discussion of the feature would be useful.

I disagree; someone may be configuring their kernel on an aeroplane
(don't laugh, I have) or other location without internet access.  A
summary of the discussion may be useful, but keep it short.

By the way, something missing from the original is "what to do if you
don't understand".  A sentence like:

	  If you don't know how to answer this question, it is safest to
	  say "N".

goes a long way.  OK, this is under DEBUG_KERNEL, but even so.

-- 
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."

Re: [PATCH] Documentation: Explain 4K stacks in slightly more

[Robert P. J. Day]

On Fri, 25 Apr 2008, Matthew Wilcox wrote:

> I just ran a grep for 4KSTACKS ... this text appears to have been
> duplicated into three other architectures, so should be updated on
> all of them together.  Except for the bit about the interrupt
> stacks; as far as I can tell, they don't do that.

all right, that's just confusing.  for one thing, 4K stacks are still
classified as a "debug" feature under x86, but apparently a regular
feature under m68knommu and back to being a debug feature under SH.
grrrrr.

i'm going to look at this more closely.  carry on.

rday
--

====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
====================================

Re: [PATCH] Documentation: Explain 4K stacks in slightly more detail.

[Nick Andrew]

On Fri, Apr 25, 2008 at 02:41:44PM -0600, Matthew Wilcox wrote:
> 	  If you don't know how to answer this question, it is safest to
> 	  say "N".

How about:

	If unsure, say "N".

Nick.
-- 
PGP Key ID = 0x418487E7                      http://www.nick-andrew.net/
PGP Key fingerprint = B3ED 6894 8E49 1770 C24A  67E3 6266 6EB9 4184 87E7

Re: [PATCH] Documentation: Explain 4K stacks in slightly more

[Robert P. J. Day]

On Sat, 26 Apr 2008, Nick Andrew wrote:

> On Fri, Apr 25, 2008 at 02:41:44PM -0600, Matthew Wilcox wrote:
> > 	  If you don't know how to answer this question, it is safest to
> > 	  say "N".
>
> How about:
>
> 	If unsure, say "N".

as matthew pointed out earlier (and i was unaware of), 4K stacks is
also an option for architectures SH and M68KNOMMU.  so i'm just going
to hold off until maybe this is centralized.

rday
--


====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
====================================