Re: RFC: i386: kill !4KSTACKS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jan Kiszka wrote:
2005/9/7, Bill Davidsen <[email protected]>:


Is there a technical reason ("hard to implement" is a practical reason)
why all stacks need to be the same size?



Because of

static inline struct thread_info *current_thread_info(void)
{
        struct thread_info *ti;
        __asm__("andl %%esp,%0; ":"=r" (ti) : "" (~(THREAD_SIZE - 1)));
        return ti;
}
[include/asm-i386/thread_info.h]

which assumes that it can "round down" the stack pointer and then will
find the thread_info of the current context there. Only works for
identically sized stacks. Note that this function is heavily used in
the kernel, either directly or indirectly. You cannot avoid it.

Avoiding it isn't necessary, a config option to read a variable THREAD_SIZE would solve this part of it. I looked at the implications of this, and other than a slight overhead it looks as if the problem is where to put the size :-( I think it could be done given that all threads of a process would have the same size, but I am *not* suggesting that it should be done.

My current assessment regarding differently sized threads for
ndiswrapper: not feasible with vanilla kernels.

Have to agree, it would take way more effort than it's worth, given that the need can be avoided by allowing user config of the stack size. It does look relatively easy to allow larger stack sizes, though. Wasn't there one driver so ill-behaved it wouldn't even run in an 8k stack?

Andi made the point that allocating server size memory in 4k blocks results in a lot of them, resulting in increased overhead in some places. Thinking about configuring the stack size, maybe it would be useful to make memory allocation block size independent of the hardware and let both be set over a wide range in config.

--
   -bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux