Paul Mundt wrote:
> On Mon, Aug 25, 2008 at 08:48:25AM +0200, Thomas Petazzoni wrote:
>> Le Tue, 19 Aug 2008 16:18:38 +0200 (CEST),
>> Geert Uytterhoeven <[EMAIL PROTECTED]> a ??crit :
>>
>>> On Tue, 19 Aug 2008, Thomas Petazzoni wrote:
[RFC] Remove more code when IP_MULTICAST=n
>>> Probably y
On Tue, Aug 26, 2008 at 10:35:05AM -0700, Linus Torvalds wrote:
>
>
> On Tue, 26 Aug 2008, Rusty Russell wrote:
> >
> > Your workaround is very random, and that scares me. I think a huge number
> > of
> > CPUs needs a real solution (an actual cpumask allocator, then do something
> > clever i
On Mon, 2008-08-25 at 01:18 +0200, Denys Vlasenko wrote:
> Hi Andrew,
>
> You asked me to maintain it and resubmit when
> merge frenzy is over.
>
> Here is the update against current Linus tree
> (which is 2.6.27-rc4-git3), rolled up into one patch.
Do you have the patches that actually use
-ff
On Tue, 26 Aug 2008, Adrian Bunk wrote:
>
> A debugging option (for better traces) to disallow gcc some inlining
> might make sense (and might even make sense for distributions to
> enable in their kernels), but when you go to use cases that require
> really small kernels the cost is too high.
On Tue, 26 Aug 2008, Adrian Bunk wrote:
>
> I added "-fno-inline-functions-called-once -fno-early-inlining" to
> KBUILD_CFLAGS, and (with gcc 4.3) that increased the size of my kernel
> image by 2%.
Btw, did you check with just "-fno-inline-functions-called-once"?
The -fearly-inlining decisi
Linus Torvalds wrote:
> The inline-functions-called-once thing is what causes even big functions
> to be inlined, and that's where you find the big downsides too (eg the
> stack usage).
That's a bit bizarre, though, isn't it?
A function which is only called from one place should, if everything
On Tue, 26 Aug 2008, Jamie Lokier wrote:
>
> A function which is only called from one place should, if everything
> made sense, _never_ use more stack through being inlined.
But that's simply not true.
See the whole discussion.
The problem is that if you inline that function, the stack usage
On Tuesday 26 August 2008 20:33, Daniel Walker wrote:
> On Mon, 2008-08-25 at 01:18 +0200, Denys Vlasenko wrote:
> > Hi Andrew,
> >
> > You asked me to maintain it and resubmit when
> > merge frenzy is over.
> >
> > Here is the update against current Linus tree
> > (which is 2.6.27-rc4-git3), rol
On Tue, Aug 26, 2008 at 11:40:10AM -0700, Linus Torvalds wrote:
>
>
> On Tue, 26 Aug 2008, Adrian Bunk wrote:
> >
> > A debugging option (for better traces) to disallow gcc some inlining
> > might make sense (and might even make sense for distributions to
> > enable in their kernels), but when
On Tue, 26 Aug 2008, Adrian Bunk wrote:
>
> I had in mind that we anyway have to support it for tiny kernels.
I actually don't think that is true.
If we really were to decide to be stricter about it, and it makes a big
size difference, we can probably also add a tool to warn about functions
On Tue, Aug 26, 2008 at 11:47:01AM -0700, Linus Torvalds wrote:
>
>
> On Tue, 26 Aug 2008, Adrian Bunk wrote:
> >
> > I added "-fno-inline-functions-called-once -fno-early-inlining" to
> > KBUILD_CFLAGS, and (with gcc 4.3) that increased the size of my kernel
> > image by 2%.
>
> Btw, did you
On Tue, 26 Aug 2008, Adrian Bunk wrote:
>
> If you think we have too many stacksize problems I'd suggest to consider
> removing the choice of 4k stacks on i386, sh and m68knommu instead of
> using -fno-inline-functions-called-once:
Don't be silly. That makes the problem _worse_.
We're much b
On Tue, Aug 26, 2008 at 5:04 PM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> And embedded people (the ones that might care about 1% code size) are the
> ones that would also want smaller stacks even more!
This is something I never understood - embedded devices are not going
to run more than a few
Parag Warudkar wrote:
On Tue, Aug 26, 2008 at 5:04 PM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
And embedded people (the ones that might care about 1% code size) are the
ones that would also want smaller stacks even more!
This is something I never understood - embedded devices are not going
On Tue, Aug 26, 2008 at 02:04:57PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 26 Aug 2008, Adrian Bunk wrote:
> >
> > If you think we have too many stacksize problems I'd suggest to consider
> > removing the choice of 4k stacks on i386, sh and m68knommu instead of
> > using -fno-inline-functio
On Tue, Aug 26, 2008 at 04:00:33PM -0700, David VomLehn wrote:
> Parag Warudkar wrote:
>> On Tue, Aug 26, 2008 at 5:04 PM, Linus Torvalds
>> <[EMAIL PROTECTED]> wrote:
>>
>>> And embedded people (the ones that might care about 1% code size) are the
>>> ones that would also want smaller stacks even
On Tue, 26 Aug 2008, Parag Warudkar wrote:
>
> This is something I never understood - embedded devices are not going
> to run more than a few processes and 4K*(Few Processes)
> IMHO is not worth a saving now a days even in embedded world given
> falling memory prices. Or do I misunderstand?
We
On Wed, 27 Aug 2008, Adrian Bunk wrote:
> >
> > We're much better off with a 1% code-size reduction than forcing big
> > stacks on people. The 4kB stack option is also a good way of saying "if it
> > works with this, then 8kB is certainly safe".
>
> You implicitely assume both would solve the
On Tue, Aug 26, 2008 at 04:51:52PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 27 Aug 2008, Adrian Bunk wrote:
> > >
> > > We're much better off with a 1% code-size reduction than forcing big
> > > stacks on people. The 4kB stack option is also a good way of saying "if
> > > it
> > > works wit
On Wed, 27 Aug 2008, Adrian Bunk wrote:
>
> When did we get callpaths like like nfs+xfs+md+scsi reliably
> working with 4kB stacks on x86-32?
XFS may never have been usable, but the rest, sure.
And you seem to be making this whole argument an excuse to SUCK, adn an
excuse to let gcc crap eve
Linus Torvalds wrote:
On Tue, 26 Aug 2008, Parag Warudkar wrote:
This is something I never understood - embedded devices are not going
to run more than a few processes and 4K*(Few Processes)
IMHO is not worth a saving now a days even in embedded world given
falling memory prices. Or do I misun
On Tue, Aug 26, 2008 at 7:47 PM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> If that matters, then so should the difference of 3-8 processes' kernel
> stack usage when you have a 4k/8k stack choice.
The savings part -financial ones- are not always realizable with the
way memory is priced/sized/fi
On Tue, Aug 26, 2008 at 8:53 PM, Greg Ungerer <[EMAIL PROTECTED]> wrote:
> I have some simple devices (network access/routers) with 8MB of RAM,
> at power up not really being configured to do anything running 25
> processes. (Heck there is over 10 kernel processes running!). Configure
> some inter
Parag Warudkar wrote:
On Tue, Aug 26, 2008 at 8:53 PM, Greg Ungerer <[EMAIL PROTECTED]> wrote:
I have some simple devices (network access/routers) with 8MB of RAM,
at power up not really being configured to do anything running 25
processes. (Heck there is over 10 kernel processes running!). Co
On Tue, 26 Aug 2008, Parag Warudkar wrote:
>
> And although you said in your later reply that Linux x86 with 4K
> stacks should be more than usable - my experiences running a untainted
> desktop/file server with 4K stack have been always disastrous XFS or
> not. It _might_ work for some well def
On Tue, Aug 26, 2008 at 9:31 PM, Greg Ungerer <[EMAIL PROTECTED]> wrote:
>
> And the pressure will still be on in _real_ products to reduce
> the RAM footprint as much as possible. There are exceptions but
> generally less is cheaper. Simple economics really.
Well, sure - but the industry as a w
On Tue, Aug 26, 2008 at 9:49 PM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 26 Aug 2008, Parag Warudkar wrote:
>>
>> And although you said in your later reply that Linux x86 with 4K
>> stacks should be more than usable - my experiences running a untainted
>> desktop/file server with 4K
On Tue, 26 Aug 2008, Parag Warudkar wrote:
>
> What about deep call chains? The problem with the uptake of 4K stacks
> seems to be that is not reliably provable that it will work under all
> circumstances.
Umm. Neither is 8k stacks. Nobody "proved" anything.
But yes, some subsystems have insan
I have a PPC440GX based board.
Do I need to reinitialize Peripheral Bank Configuration Registers
(EBC0_B0CR-EBC0_B7CR) from the kernel ?
I'm quite sure that we don't, but just want to make sure. Because the problem
that i'm seeing strongly suggest that it's probably not accessible.
Here's the p
Linus Torvalds writes:
> 4kB used to be the _only_ choice. And no, there weren't even irq stacks.
> So that 4kB was not just the whole kernel call-chain, it was also all the
> irq nesting above it.
I think your memory is failing you. In 2.4 and earlier, the kernel
stack was 8kB minus the size
30 matches
Mail list logo
