lkml.org 
[lkml]   [1999]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Per-Processor Data Page
Date
From
> I'll disagree cheerfully with this.   I've a bit of experience
> in the area and find that the bulk of serious multithreaded applications
> use and desire pthreads.

For portability or for performance. You have a choice of exactly one API
for threading portably on Unix. It isnt a brilliant API but it works. So
people use it

> industry. Pthreads are quite extensively used in large SMP applications.

Because it is portable.

> In any case, pthreads support is required by the Single Unix Specification,
> and divergence from that does neither linux nor the unix community in general
> any good whatsoever. Let's not try to out-microsoft microsoft.

And SuS also is far from perfect. Its a hacked together ratification of
evolved behaviour. In places it reminds me of the cobol 2000 spec although
thankfully it hasnt gone quite that far.

Supporting SuS is important (except for really sick crap like streams), but
optimising for the sillier cases is questionable to say the least. Linux
doesn't meet all the SuS atomicity of reads v writes guarantees for
example.

> Of course they can, however, they have all the pitfalls and deficiencies
> of the kernel mechanism, one of which is the requirement that thread
> stacks be fixed size which is not compatible with pthreads either as
> defined by POSIX or as adopted by the Open Group.

It doesnt require fixed size stacks. It might require the allocator places
the intelligently to leave suitable holes.

> > use one for thread storage. The %esp trick overhead generally outweighs
> > the TLB flush overheads and nowdays is cheaper than segment overrides
>
> Only if you are willing to live within the limitations of the trick,
> which may prevent portable software from being usable on linux.

Segment overrides are x86 only. Your point ?

> between two clones sharing an address space. It will cause a TLB flush
> in some (perhaps boundary) cases of two threads in the same address
> space are being switched between. I don't consider this typical (see
> earlier post to Ingo Molnar).

When I'm watching a DVD on Linux there are five threads switching at a high
rate. I think thats not atypical. A measurable chunk of the linux clone
thread performance comes from totally shared page tables, no tlb flushes
and misses.

> The ability to, for example, allocate scatter-gather lists on the kernel
> stack rather than call a memory allocator in the I/O path would be a
> win. Likewise for the struct kiobuf.

For small lists you can do this.

> > No. Your allocation might fail in an irq, or you might need to do a stack
> > grow during a block I/O page out to allocate memory. Deadlock death.
>
> Keep a reserved page per processor for this very eventuality. Take the
> page back before dismissing the interrupt. Panic if the subsequent
> guard page is hit (assuming a recursive loop error).

It isnt an error to hit the extra page. If you have expandable stacks then
you have to be able to fulfill the expansion. Ultimately that means all
stack usage has to be blocking. That or your stacks are only "kind of"
growable and it blows up by magic if you get it wrong.

Switching to a virtually contiguous stack in order to get guard pages is
a possible good plan for the future. (Right now people still DMA off the
stack although the department of shooting people is working on this issue)

> True for getpid, that was a bad example on my part.
> It is not necessarily true for gettimeofday(), times(),
> kernel random number seed and other data frequently required
> from the kernel; The kernel could even use it to export
> code to user-mode, e.g. for signal handling.

Exporting code is a useful one. We can export the same code to all. Similarly
the time of day and the like can be globally exported because they are shared.
Every thread on the system has the same time.

That gives you all sorts of benefits - especially the code hooks, but without
the extra cost of page tables, tlb abuse and the like.

Alan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.227 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site