linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Threads and the LDT (Intel-specific)?
       [not found] <01061011532900.01126@abacus.suse.lists.linux.kernel>
@ 2001-06-13  9:15 ` Andi Kleen
  0 siblings, 0 replies; 3+ messages in thread
From: Andi Kleen @ 2001-06-13  9:15 UTC (permalink / raw)
  To: Scott Long; +Cc: linux-kernel

Scott Long <smlong@teleport.com> writes:

> I can also use the LDT to point to thread-specific segments. IMHO this 
> is much better than the stack trick used by linuxthreads. The problem 

Modern LinuxThreads (glibc 2.2) also uses modify_ldt for thread local data
(much to the pain of the IA64 and x86-64 ports who have to emulate it..) 

> is, I don't fully understand how to use modify_ldt(). Is anyone 
> knowledgeable about this?

modify_ldt() works like a memcpy to/from the ldt. See the man page. On the
layout of the LDT see the intel IA32 architecture manual from http://developer.intel.com
 
> If anyone has any other suggestions, please let me know. If you are 
> confused as to why I would ever want to do this in the first place, I'd 
> be willing to go over it off the list.

I can imagine, but it'll cost you. Most modern CPUs have heavy penalties for
non-zero-based or limited segments (a few cycles for every memory access) and LDT
switching also makes the context switch slower.

An portable alternative is to use multiple processes with a shared memory area.

-Andi

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Threads and the LDT (Intel-specific)?
@ 2001-06-10 18:53 Scott Long
  2001-06-10 18:40 ` Jeff Dike
  0 siblings, 1 reply; 3+ messages in thread
From: Scott Long @ 2001-06-10 18:53 UTC (permalink / raw)
  To: linux-kernel

I'm trying to do something a bit unorthodox: I want to share the 
address space between threads, but I want a certain region of the 
address space to be writeable only for a particular thread -- for all 
other threads this region is read-only.

I've considered several approaches. I'll only go over the one I think 
is the best solution. I would appreciate any comments folks might have:

When linking the userspace program, I instruct the linker to avoid the 
region from VMA 0 to VMA 0x400000. Then, in the userspace code, I 
duplicate the GDT entries for CS, DS, ES, SS into the LDT, except that 
the new segments begin at 0x400000, instead of 0. I load the segment 
registers with these LDT entries. In the "write-allowed" thread I 
create an LDT entry to address VMA 0 through VMA 0x400000, in 
read-write mode. In all the other threads I create an LDT entry to 
address the same area in read-only mode. This gives me a 4M region at 
the bottom of memory that is accessible in different ways to different 
threads.

I can also use the LDT to point to thread-specific segments. IMHO this 
is much better than the stack trick used by linuxthreads. The problem 
is, I don't fully understand how to use modify_ldt(). Is anyone 
knowledgeable about this?

If anyone has any other suggestions, please let me know. If you are 
confused as to why I would ever want to do this in the first place, I'd 
be willing to go over it off the list.

Thanks,
Scott

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Threads and the LDT (Intel-specific)?
  2001-06-10 18:53 Scott Long
@ 2001-06-10 18:40 ` Jeff Dike
  0 siblings, 0 replies; 3+ messages in thread
From: Jeff Dike @ 2001-06-10 18:40 UTC (permalink / raw)
  To: Scott Long; +Cc: linux-kernel

smlong@teleport.com said:
> I'm trying to do something a bit unorthodox: I want to share the
> address space between threads, but I want a certain region of the
> address space to be writeable only for a particular thread -- for all
> other threads this region is read-only. 

UML does this in a somewhat portable (but strange) way.  Threads don't share 
address spaces, as far as the OS is concerned, but the areas where the 
executable is mapped in are copied to a file, those areas are mapped out, and 
the files mapped shared in their place.  This happens once, in the first 
thread, and all subsequent threads get the executable mapped shared 
automatically, even though they are separate processes and separate address 
spaces from the point of view of the kernel.

So, once this is set up, a thread just makes an area read-write (or readonly) 
and that mapping is private.

				Jeff



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-06-13  9:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <01061011532900.01126@abacus.suse.lists.linux.kernel>
2001-06-13  9:15 ` Threads and the LDT (Intel-specific)? Andi Kleen
2001-06-10 18:53 Scott Long
2001-06-10 18:40 ` Jeff Dike

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).