Re: SCO: "thread creation is about a thousand times faster than on native Linux"
> But if you can get rid of the stacks, and you _can_ get rid of the > stacks sometimes, then why not have one thread per widget in a GUI? Or > one thread per animated objected on a web page? Some notions of For this to work without opening up a security hole we must be able to distribute the processor timeslice for a process among all of it's threads. Please correct me if I am wrong but AFAIK this is impossible with the current scheduler logic. Tom Growing old is mandatory... growing up is optional. -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 mail [EMAIL PROTECTED] PGP signature
Re: SCO: "thread creation is about a thousand times faster than on native Linux"
> quote> SCO's Juergen Kienhoefer tells us that by mapping clone processes > quote> directly onto UnixWare's native threads, huge performance gains > quote> can be realised. "Basically thread creation is about a thousand > quote> times faster than on native Linux," he said. The performance boost > quote> could particularly benefit applications such as Domino, according > quote> to Kienhoefer. *ROTFL* As they are referring to Domino as an application that can benefit from faster thread creation they obviously do not have any clue what performance and threading is all about. I would put this in the same folder as the 'Linux is Open Source and hence cannot be secured' message before - this was /dev/null here. Tom Quantum Mechanics is God's version of "Trust me." -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 mail [EMAIL PROTECTED] PGP signature
Re: SCO: "thread creation is about a thousand times faster than on
Hi! > > CODA's local caching is pretty much neccessity: you can't have > > read/write server in userland on localhost at smaller granularity due > > to deadlock issues. > > For distributed filesystem - yes (but not necessary). For other kinds of > stuff - provably not true. Okay, how do you implement it? There's memory pressure, kernel needs ram. So it decides to write some old data to disk. Data go to userland process on same machine; but we already know we are short of memory. Userland process is likely to get stopped due to low memory and you are deadlocked. You could pagelock userland server to solve this. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Fri, 1 Sep 2000, Pavel Machek wrote: > CODA's local caching is pretty much neccessity: you can't have > read/write server in userland on localhost at smaller granularity due > to deadlock issues. For distributed filesystem - yes (but not necessary). For other kinds of stuff - provably not true. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Hi! > > * podfuk is has file granularity > > > > I could see it working with some kind of directory format, however.] > > Yep. And quite a few mailreaders can work with that. I'm less than sure > that CODA's local caching is appropriate, though. More RPC-oriented > stub CODA's local caching is pretty much neccessity: you can't have read/write server in userland on localhost at smaller granularity due to deadlock issues. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Thu, 31 Aug 2000, Erik McKee wrote:
> Hello!
>
> This is one of my first posts here, so try to be gentle, please ;)
>
> Seems like if a thread which shares a VM with all the other threads of the
> same family does an execve, the following would be likely to occurr, using
> the standard definition of execve. The vm would be overwriteen with the
> new image, but this would have to wwipe out all the other threads in the
> process, 'cuz otherwise everything they refer to has just been overwritten
> by the results of the execve. However, if the execve'ing thread was
> allowed to spawn off intop a new address space before the execve, it would
> then become a new process, and leave the parent procvess with one less
> thread to worry about.
I think that's close to Linus' idea.
But it reminds me more a fork()+exec() rather than a simple exec().
OK. I'm clueless C programmer. I write:
program A:
pid = getpid(); /* imagine is 300 */
...
exec("program B");
program B:
...
pid = getpid(); /* I'm expecting 300 */
Then I modify A:
program A2:
pid = getpid(); /* 400 */
if (!fork()) {
exec("program B);
}
...
program B:
...
pid = getpid(); /* I'm expecting != 400 */
This is ok because that's what I asked for.
Suppose I make a MT version of A. It would behave just like A2.
The thread who's performing the exec() becomes a different process
and program B sees a different pid.
It's like saying: an exec() in a MT process behaves like a fork()+exec()
sequence in a normal process.
I'm not really against it... it's just a little weird.
Killing all threads, and doing a "real" exec(), leads to the expected
semantic. Of course, since you should expect the "defined" semantic,
that matter is about choosing the definition. B-)
BTW, I don't think it needs to be a kernel matter. exec() in a MT
program can be defined to kill all threads in userland before doing
the exec().
>
> Or am I being very stupid and overlooking something critical here?
Do you consider the above problem "critical"? B-)
>
> Have a nice day ;)
> Erik McKee
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Hello! This is one of my first posts here, so try to be gentle, please ;) Seems like if a thread which shares a VM with all the other threads of the same family does an execve, the following would be likely to occurr, using the standard definition of execve. The vm would be overwriteen with the new image, but this would have to wwipe out all the other threads in the process, 'cuz otherwise everything they refer to has just been overwritten by the results of the execve. However, if the execve'ing thread was allowed to spawn off intop a new address space before the execve, it would then become a new process, and leave the parent procvess with one less thread to worry about. Or am I being very stupid and overlooking something critical here? Have a nice day ;) Erik McKee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
[EMAIL PROTECTED] (Linus Torvalds) wrote on 27.08.00 in <[EMAIL PROTECTED]>: > On Sun, 27 Aug 2000, Alexander Viro wrote: > > > > Linus, there is no need in new mask for execve(). > > What you're saying is "there are other ways to accomplish this". And I > kind of agree. I still think the dynamic mask is the preferable option. > > > We have two actions: > > 1. create a VM set up according to the contents of binary > > Sure. Another ELF marker, whatever. It would work, and probably cover the > needs. Especially as "the needs" aren't that big, as this has actually > never come up except as a theoretical discussion ;). Just don't forget that some of this unsharing may be necessary for security reasons. Specifically, when you execve() a suid program, you probably should automatically unshare everything. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Tue, 29 Aug 2000, Pavel Machek wrote: > What does this have to do with private namespaces? Albert asked what to do if /var/spool/mail dies and every user has his own namespace. Well, don't let him play with /var/spool/mail directly... > mailfsd /dev/coda0 --enable-imap & > mount /dev/coda0 /var/spool/mail > > It looks easy to me, today and without private namespaces. > [Shall I hack podfuk into providing imap? Okay, it would not be easy > because > * /var/spool/mail/xxx is _writable_, so your imap dream is probably > dream. What does your mailfs do when someone does cat /bin/bash > > $MYMAIL Commit-on-close is one of the obvious variants... > * podfuk is has file granularity > > I could see it working with some kind of directory format, however.] Yep. And quite a few mailreaders can work with that. I'm less than sure that CODA's local caching is appropriate, though. More RPC-oriented stub in the kernel might augment it quite fine and in that case it would probably work better. Or not... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Tue, 29 Aug 2000, Pavel Machek wrote: > Hi! > [...] > > > So you need some hackery to make mount(8) cause change in all > > > namespaces at once. Whatever is done, this will be gross. > > > I suppose you'd require a loopback of some sort, so that one > > > might rip the real filesystem out from under /var/mail instead > > > of trying to unmount it in 50 different namespaces... ugh. > > > > Not. Loopback would be gross, but I'm not proposing it. OTOH, getting all > > mailreaders work with IMAP with _no_ changes in said mailreaders is a > > Good Thing(tm). So is free (for mailreaders) support of any weird > > protocol, format and location of mailbox, locking scheme, etc. - do it in > > one place and that's it. Everything looks like we have the mailbox in > > fixed format on local filesystem, no matter WTF is actually out there. > > And guess what? It doesn't have to be one process and it's nowhere near > > the kernel mode, or even suid. > > What does this have to do with private namespaces? > > mailfsd /dev/coda0 --enable-imap & > mount /dev/coda0 /var/spool/mail So every user will see /var/spool/mail. There must be a single mailfsd for all users. With private namespaces, every user can run his/her own mailfsd, privately mount /var/spool/mail, and run a mailer program to access one or more IMAP mailbox as /var/spool/mail/. But I must say I don't really get the difference in running my own mailfsd, mounting ~/mail and having the mailer program read IMAP mailboxes there (OK, /var/spool/mail/ is the default INBOX for many mailers, and some of them don't let you change that... but this is a minor issue, just recompile them). All I need is a private mount point (and privileges to mount on it). > > It looks easy to me, today and without private namespaces. > [Shall I hack podfuk into providing imap? Okay, it would not be easy > because > * /var/spool/mail/xxx is _writable_, so your imap dream is probably > dream. What does your mailfs do when someone does cat /bin/bash > > $MYMAIL > * podfuk is has file granularity > > I could see it working with some kind of directory format, however.] > Pavel > -- > I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." > Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Hi! > > > Erm? > > > * setuid is a fscking wart - THE mistake of dmr and/or ken. > > > > If not urban legend, dmr was the patent owner. > > Erm... That would be a nice way to bury one's mistake - patent it and > refuse to license ;-) Unfortunately, didn't happen... (-: > > So you need some hackery to make mount(8) cause change in all > > namespaces at once. Whatever is done, this will be gross. > > I suppose you'd require a loopback of some sort, so that one > > might rip the real filesystem out from under /var/mail instead > > of trying to unmount it in 50 different namespaces... ugh. > > Not. Loopback would be gross, but I'm not proposing it. OTOH, getting all > mailreaders work with IMAP with _no_ changes in said mailreaders is a > Good Thing(tm). So is free (for mailreaders) support of any weird > protocol, format and location of mailbox, locking scheme, etc. - do it in > one place and that's it. Everything looks like we have the mailbox in > fixed format on local filesystem, no matter WTF is actually out there. > And guess what? It doesn't have to be one process and it's nowhere near > the kernel mode, or even suid. What does this have to do with private namespaces? mailfsd /dev/coda0 --enable-imap & mount /dev/coda0 /var/spool/mail It looks easy to me, today and without private namespaces. [Shall I hack podfuk into providing imap? Okay, it would not be easy because * /var/spool/mail/xxx is _writable_, so your imap dream is probably dream. What does your mailfs do when someone does cat /bin/bash > $MYMAIL * podfuk is has file granularity I could see it working with some kind of directory format, however.] Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Tue, 29 Aug 2000, Albert D. Cahalan wrote: > Proposal 'c' is that way. If you agree that "VM is just one of > the resources" but think that there are "uses for sharing between > different programs", proposal 'a' is for you. Sorry, no. VM is the resource that execve() replaces. That is what execve() is all about - build a new VM by binary and replace the VM component of process with it. execve() doesn't modify VM - it builds a new one from scratch. IOW, it's not "load a program into existing address space". It's "build a new address space by the program and attach it to virtual machine (aka. process)". Yes, if you are the sole owner of your VM you can cannibalize mm_struct to avoid the overhead of kmem_cache_alloc(). But that should be (and is) a transparent optimisation. Think of it that way: we have virtual machines built from several components. Thread of execution is one of the components (CPU), VM is another (memory), descriptor table is IO space, etc. execve() is "build a new VM and throw the old away". fork() is "build copies of everything and make a new virtual machine out of them". clone() is "build copies of CPU and some other parts and make a new virtual machine out of them, sharing the remaining parts with the old one". exit() is "throw the virtual machine away". Heh. USENIX paper title: "Ghostwheel: Use of Reflections in Implementation of rfork()-style Threads"... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Alan Cox wrote: > It isnt a sensible answer. Think about a threaded web server firing off > cgi scripts. You should probably kill those with the same mm. Especially if > you have an unclone(CLONE_MM) since you can then unshare the VM for a thread > and exec stuff off it Think about a single threaded web server using vfork(). Then you mustn't kill tasks with the same mm. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Alexander Viro writes: > On Tue, 29 Aug 2000, Albert D. Cahalan wrote: [interaction w/ setuid, close-on-exec, and personality pseudo-roots] > We _have_ this interaction. In case you've missed it, sys_personality() > that really happens to change personality unshares fs_struct. Has to. > Rule: you do crap, _you_ pay with inconveniences. Point-blank restriction > of sharing anything to the beasts that run the same binary is *CRAP*. BTW, I've yet to see a good use for all-but-VM sharing after exec. Unsharing everything in the exec lets one avoid a system call. Unsharing nothing makes exec smaller and faster. > Same > moronic "it's a part of process" approach. Totally unjustified in case > of Linux, because here thread == process. Get over the POSIX model. I'm very much not obsessed with kernel-enforced POSIX, but it is good to reduce the hoops glibc has to jump through. Reality involves getting pthreads to be half-way fast. If a pthread_exec() system call would really help, why not? As a separate system call it shouldn't be too offensive. > VM is > just one of the resources. There are legitimate uses for sharing between > different programs. Your proposal prohibits them. Proposal 'c' is that way. If you agree that "VM is just one of the resources" but think that there are "uses for sharing between different programs", proposal 'a' is for you. Want to unshare VM? Do it, with the new unshare() call. Want rope to hang yourself? Do an exec while multiple threads are running, most of which will crash when the VM changes right under them. If a close-on-exec shared with the child would hurt, Don't Do That. Personalities make life fun when you randomly exec unknown executables into your thread group. This is clean and fast. Only the setuid wart needs to be handled. All the other kernel bloat just goes away. >> The explanation still sucks quite severely. The personality and setuid >> problems are particulary gross, because they depend on what executable >> is being started. Behavior changes drasticly when one merely >> recompiles with an alternate personality. > > Which is kinda the point of personality, no? Sure, but normally this disease only afflicts one task. With the personality code doing an unshare, there is no way for the original thread group to know what will remain shared after the exec. For an app, getting back an error code may be most desirable. (not saying the implementation would be trivial) >> If you simply unshare on exec, all this special-case crap goes away. >> The "kill other threads" option also has this nice property, and the >> "let user shoot foot" option only suffers from the setuid wart. > > Look: your sematics can be trivially achieved with the > share-whatever-we-can one. Noting could be easier, > unshare(CLONE_ALL); > execve(...); > and that's it - precisely what were asking for, unambiguous, > works regardless of the execve() details. Now, try to get the > other way round. Can't do it. Hey, that works for the VM too. An "unshare if you like" policy lets one have plenty of clean and fast rope. > "If we shove this box into the car half of us will have to take > the bus" is fine and sane. > "... so let's make everyone always take the bus" is straight from > the Dilbert-land. Fine, plan 'a' then: "If you are stupid enough to pack a full load of people into a car that is already half full, some of the people might get injured or killed. Don't do that." Either plan will reduce the special-case crap. The POSIX way also works, if you're into that sort of thing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
From: "David Howells" <[EMAIL PROTECTED]> > > Would it be possible to make fork() or clone() from a process whose tgid!=pid > reparent the child to the thread group leader automatically? Thus, when the > creating thread goes away, the child is still a child of the "process", and > SIGCHLD is still going to go to the process (leader thread). > No need--- it's userspace-solvable; we just need a rule that says "fork() in a thread is actually a clone(...|CLONE_PARENT,...)" and the magic happens all by itself. > Also all child "processes" and "threads" are then logically children of the > "process", given that a "process" is then defined by the tgid. > > Also my 2p on the execve() problem: if the master thread does an execve(), > there must be a point of no return, at which point all the child threads > should be deleted, IMHO, otherwise they turn into full processes in their own > right, and the thread-signalling framework goes out the window. > > And for a further thought on the subject, is it possible for when a child > thread does an execve(), to wangle the master thread into making this call, > with all other threads SIGSTOP'd until completion (& death) or failure (& > resumption)? (though that's probably better done in userspace) Exactly. Userspace is the key. (We just probably need a 'parent has exec()ed' notification signal in the children, like the current 'parent has exit()ed' one). -az - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Would it be possible to make fork() or clone() from a process whose tgid!=pid reparent the child to the thread group leader automatically? Thus, when the creating thread goes away, the child is still a child of the "process", and SIGCHLD is still going to go to the process (leader thread). Also all child "processes" and "threads" are then logically children of the "process", given that a "process" is then defined by the tgid. Also my 2p on the execve() problem: if the master thread does an execve(), there must be a point of no return, at which point all the child threads should be deleted, IMHO, otherwise they turn into full processes in their own right, and the thread-signalling framework goes out the window. And for a further thought on the subject, is it possible for when a child thread does an execve(), to wangle the master thread into making this call, with all other threads SIGSTOP'd until completion (& death) or failure (& resumption)? (though that's probably better done in userspace) David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
