Re: [PATCH] fork failures on ix86

MOLNAR Ingo (mingo@valerie.inf.elte.hu)
Wed, 8 Jul 1998 15:38:26 +0200 (MET DST)


On Wed, 8 Jul 1998, Rik van Riel wrote:

> I wasn't talking about the vmalloc()ed area. I meant to
> say that the 8kB piece allocated by fork() doubles as a
> kernel stack for the process.

[oops, sorry]

OTOH this should be quite rare (happened to me in the aic7xxx driver), and
can be considered a bug. (it never was a clean method as the kernel stack
is not greally guaranteed to be DMA-able say on ISA boxes) Such a driver
would definitely break on certain Sparcs where the kernel stack is already
'virtual'.

and vmalloc() is not _that_ slow, at least on x86. It is conceptually slow
whenever we have to set up a new 4MB kernel virtual memory space and have
to update all existing page tables in the system. This happens every 512th
allocation. (not with vmalloc(), but with a virtual kstack_alloc().
vmalloc() has other baggage like 'safety gaps' which are not quite needed
if we use the concept for kernel stacks)

the method of 'falling back to vmalloc()' is broken too, the ultimate goal
is to use 4k blocks and to not use up 8k blocks. Either we completely
remove the 'has to be physically continuous' restriction to help
fragmentation issues, or we dont do it all.

the transition to 'virtual stacks' can be done safely by putting some
checks into virt_to_bus() for the transition period.

i disagree with the opinion that having 'virtual kernel stacks' is an
unacceptable slowdown. Those mappings are constant during the lifetime of
the process, so we only have _slightly_ higher setup cost when creating
the task. (on x86 that is) The only slowdown is slightly more TLB usage
when compared to 4MB pages stacks, but i think that even this is
debatable.

> That is almost exactly what I said :)

[sorry :)]

> I'm busy on the allocator, but there are certain other things
> that have priority right now. This is mainly because the
> allocator probably isn't going to make it before 2.2 anyway.
> It also is because I don't want another allocator that's been
> put together in a hurry, I want one that supports _all_ wanted
> and needed features. This takes some time to design properly...

no allocator will fix our 'framgentation problems', they are purely
theoretical. So if you aim for a 'solution that solves all problems', you
will probably be disappointed at the end. I think we should fine-tune what
we have for 2.2.

-- mingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu