From: Joerg Pommnitz <pommn...@yahoo.com>
Subject: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.if1nt1v.11k6tqs@ifi.uio.no>#1/1
X-Deja-AN: 661611644
Original-Date: Wed, 23 Aug 2000 10:10:02 -0700 (PDT)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <20000823171002.14770.qmail@web207.mail.yahoo.com>
To: linux-ker...@vger.kernel.org
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
Hi Lists,
The Register has an article about the Linux compatibility layer
for Unixware.
The article claims
http://www.theregister.co.uk/content/1/12733.html
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
to
quote> Kienhoefer.
Somehow I doubt this. I could believe that the glibc pthread layer
causes a lot of overhead for the thread creation, but I cannot
imagine that they get clone 1000 times faster than the Linux kernel.
Comments?
Joerg
=====
--
Regards
Joerg
__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Tigran Aivazian <tig...@veritas.com>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.le7bhov.1qnmg3f@ifi.uio.no>#1/1
X-Deja-AN: 661616800
Original-Date: Wed, 23 Aug 2000 18:29:28 +0100 (BST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <Pine.LNX.4.21.0008231824320.1365-100000@saturn.homenet>
References: <fa.if1nt1v.11k6tqs@ifi.uio.no>
To: Joerg Pommnitz <pommn...@yahoo.com>
X-Sender: tig...@saturn.homenet
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, 23 Aug 2000, Joerg Pommnitz wrote:
> Hi Lists,
> The Register has an article about the Linux compatibility layer
> for Unixware.
> The article claims
>
> http://www.theregister.co.uk/content/1/12733.html
>
> 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
> to
> quote> Kienhoefer.
>
> Somehow I doubt this. I could believe that the glibc pthread layer
> causes a lot of overhead for the thread creation, but I cannot
> imagine that they get clone 1000 times faster than the Linux kernel.
>
> Comments?
It is plausible that individual _lwp_create(2) is faster than individual
clone(CLONE_VM) one (possibly between 5x and 10x times, the 1000x figure
is ridiculous). However, one should look a bit further and ask if native
kernel-level UW7 lwps are delivering the same set of rich functionality as
Linux clone'd tasks. IMHO, they simply don't. So one has to add all the
overhead of turning a "raw" lwp into a useful and useable thread, e.g. as
used by userspace thread concept. If you do that, no doubt you will find
that Linux performance is greater than of any commercial alternatives.
So, until Juergen points us to a ftp://... URL where one can download his
Linux kernel emulation layer for UW7 kernel (and, of course, I assume no
GPL breakage is done?) which I can pkgadd on my UW7 machine and run some
multi-threaded Linux app and see it "1000x times faster", I will ignore
the theregister article as meaningless hype. Go and thou do likewise ;)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <linux.kernel.39A407B9.9BA92DE6@timpanogas.com>#1/1
X-Deja-AN: 661656577
Approved: n...@nntp-server.caltech.edu
Organization: TRG, Inc.
X-To: Joerg Pommnitz <pommn...@yahoo.com>
Content-Type: text/plain; charset=us-ascii
X-CC: linux-ker...@vger.kernel.org
MIME-Version: 1.0
Newsgroups: mlist.linux.kernel
This whole SCO thing is overrated. I worked on the Unixware code base
at Novell, and it's
putrid in comparison to Linux. It's got a lot of good apps, but so does
Linux. This kind of tripe propaganda is what the "cult" followers of
Unixware are good at. They lost @ $ 38,000,000 dollars each year at
Novell ramming UnixWare down our throats and pissing of our customers --
Novell finally cut rheir losses and sold it. Don't get me wrong, it's
decent Unix stuff, but Linux is tons better as a general purpose PC
Unix. Just remember, Caldera is a LINUX company -- they will take the
best of both, and use it to improve Linux ....
:-)
Jeff
Joerg Pommnitz wrote:
>
> Hi Lists,
> The Register has an article about the Linux compatibility layer
> for Unixware.
> The article claims
>
> http://www.theregister.co.uk/content/1/12733.html
>
> 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
> to
> quote> Kienhoefer.
>
> Somehow I doubt this. I could believe that the glibc pthread layer
> causes a lot of overhead for the thread creation, but I cannot
> imagine that they get clone 1000 times faster than the Linux kernel.
>
> Comments?
>
> Joerg
>
> =====
> --
> Regards
> Joerg
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Tigran Aivazian <tig...@veritas.com>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <linux.kernel.Pine.LNX.4.21.0008231833540.1365-100000@saturn.homenet>#1/1
X-Deja-AN: 661636190
Approved: n...@nntp-server.caltech.edu
X-To: "Jeff V. Merkey" <jmer...@timpanogas.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
X-cc: Joerg Pommnitz <pommn...@yahoo.com>, linux-ker...@vger.kernel.org
Newsgroups: mlist.linux.kernel
On Wed, 23 Aug 2000, Jeff V. Merkey wrote:
> Just remember, Caldera is a LINUX company -- they will take the
> best of both, and use it to improve Linux ....
>
> :-)
Hi Jeff,
Good stuff, but what I am still wondering is whethere is indeed anything
in UnixWare (or any other commercial UNIX) that can be used to improve
Linux. Pray do tell us, what do you think such areas might be?
At the moment, I can't think of any, and I did work as a UnixWare7 kernel
escalations engineer for 2 years :)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Tigran Aivazian <tig...@veritas.com>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <linux.kernel.Pine.LNX.4.21.0008231843060.1365-100000@saturn.homenet>#1/1
X-Deja-AN: 661636179
Approved: n...@nntp-server.caltech.edu
X-To: "Jeff V. Merkey" <jmer...@timpanogas.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
X-cc: Joerg Pommnitz <pommn...@yahoo.com>, linux-ker...@vger.kernel.org
Newsgroups: mlist.linux.kernel
On Wed, 23 Aug 2000, Tigran Aivazian wrote:
> Good stuff, but what I am still wondering is whethere is indeed anything
> in UnixWare (or any other commercial UNIX) that can be used to improve
> Linux. Pray do tell us, what do you think such areas might be?
I do correct myself - there is one thing in UW7 that is definitely worth
using under Linux - the VERITAS vxfs journalling filesystem, i.e. ;)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: "Andi Kleen" <a...@suse.de>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.itvsgev.v2klpf@ifi.uio.no>#1/1
X-Deja-AN: 661620332
Original-Date: Wed, 23 Aug 2000 19:38:14 +0200
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <20000823193814.A24509@gruyere.muc.suse.de>
References: <fa.le7bhov.1qnmg3f@ifi.uio.no>
To: Tigran Aivazian <tig...@veritas.com>
Original-References: <20000823171002.14770.qm...@web207.mail.yahoo.com>
<Pine.LNX.4.21.0008231824320.1365-100...@saturn.homenet>
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, Aug 23, 2000 at 06:29:28PM +0100, Tigran Aivazian wrote:
> It is plausible that individual _lwp_create(2) is faster than individual
> clone(CLONE_VM) one (possibly between 5x and 10x times, the 1000x figure
> is ridiculous). However, one should look a bit further and ask if native
> kernel-level UW7 lwps are delivering the same set of rich functionality as
> Linux clone'd tasks. IMHO, they simply don't. So one has to add all the
> overhead of turning a "raw" lwp into a useful and useable thread, e.g. as
> used by userspace thread concept. If you do that, no doubt you will find
> that Linux performance is greater than of any commercial alternatives.
The main problem Linux clone has over LWPs is the extensive memory resource
usage (~8.5K on x86, 16+somethingK on 64bit for the kernel stacks)
To solve that it would be very nice to have Mach like continuations in
Linux (multiple kernel threads sharing a kernel stack)
Also the LinuxThreads library does horrible things at pthread_create time,
like doing a full context switch to the manager thread and cloning from
there (mostly to work around signal/waitpid() problems in the kernel)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: "Albert D. Cahalan" <acaha...@cs.uml.edu>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.gaai08v.f1s71u@ifi.uio.no>#1/1
X-Deja-AN: 661638550
Original-Date: Wed, 23 Aug 2000 14:22:53 -0400 (EDT)
Sender: linux-kernel-ow...@vger.kernel.org
Content-Transfer-Encoding: 7bit
Original-Message-Id: <200008231822.e7NIMrN167635@saturn.cs.uml.edu>
References: <fa.if1nt1v.11k6tqs@ifi.uio.no>
To: pommn...@yahoo.com (Joerg Pommnitz)
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
Joerg Pommnitz writes:
> 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
...
> Somehow I doubt this. I could believe that the glibc pthread layer
> causes a lot of overhead for the thread creation, but I cannot
> imagine that they get clone 1000 times faster than the Linux kernel.
So glibc overhead is nearly a factor of 1000. Film at 11.
Ulrich Drepper has repeatedly flamed Linus for not adding the
features needed for low-overhead POSIX threads. Linus thinks
the POSIX thread interface is broken, so he won't add the ugly
bits needed to sanely reach POSIX compliance. Ulrich has tried
to write a fully-compliant POSIX thread API, always choosing
correctness over performance.
Thanks to this fight, we get a severely bloated almost-POSIX
monster that damn near everyone hates. The lack of a unified
source tree (as found in the BSD world) only makes this worse.
There is no global tree owner to resolve this dispute.
To POSIX or not to POSIX, that is the quarrel. Too bad that it
flushes our performance down the toilet. We've seen this before
and will see it again: sysctl, floating-point initialization...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: kuz...@ms2.inr.ac.ru
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.dktiamv.q6a1br@ifi.uio.no>#1/1
X-Deja-AN: 661645474
Original-Date: Wed, 23 Aug 2000 22:42:26 +0400 (MSK DST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-Id: <200008231842.WAA01028@ms2.inr.ac.ru>
References: <fa.itvsgev.v2klpf@ifi.uio.no>
To: a...@suse.DE (Andi Kleen)
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
Hello!
> The main problem Linux clone has over LWPs is the extensive memory resource
> usage (~8.5K on x86, 16+somethingK on 64bit for the kernel stacks)
Hmm... Andi, could you elaborate this? Does LWP need not kernel stack?
It is diffucult to believe that LWP in some OS eats less resources
than Linux process does.
> Also the LinuxThreads library does horrible things at pthread_create time,
> like doing a full context switch to the manager thread and cloning from
> there (mostly to work around signal/waitpid() problems in the kernel)
I hope, this is closer to truth.
But even closer to truth is that "thread creation" is not equal
to "LWP creation", thread may be created not entering kernel at all.
F.e. normal multithreading application with several thousands of threads
with sane thread library creates only couple of LWPs sometimes,
because LWPs are created only when they are _required_.
LinuxThreads is far from being sane in this sense.
BTW look into our scheduler, which scans all the list of idle processes
each time slice, when only one process is running really and the rest
are deathly dead. 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.il6jjov.1j4ion@ifi.uio.no>#1/1
X-Deja-AN: 661650501
Original-Date: 23 Aug 2000 11:59:42 -0700
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <8o16uu$83t$1@penguin.transmeta.com>
References: <fa.itvsgev.v2klpf@ifi.uio.no>
To: linux-ker...@vger.kernel.org
Original-References: <20000823171002.14770.qm...@web207.mail.yahoo.com>
<Pine.LNX.4.21.0008231824320.1365-100...@saturn.homenet>
<20000823193814.A24...@gruyere.muc.suse.de>
X-Authentication-Warning: palladium.transmeta.com:
mail set sender to n...@transmeta.com using -f
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Transmeta Corporation
Newsgroups: fa.linux.kernel
In article <20000823193814.A24...@gruyere.muc.suse.de>,
Andi Kleen <a...@suse.de> wrote:
>
>To solve that it would be very nice to have Mach like continuations in
>Linux (multiple kernel threads sharing a kernel stack)
Oh, Gods, no.
Continuations are evil. And they don't scale in SMP. Don't even think
about them.
Mach had a lot of bad ideas. In fact, I can't think of a single _good_
idea from Mach. This one certainly was not.
(As far as I can tell, the only reason for continuations in Mach was
that Mach performance sucks without them, and it was a way of handling
the process switches from a client process into a server process without
the overhead. Of course, the right solution to that particular problem
is to not use a microkernel at all, but that was ea bit too non-radical
for the Mach guys).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.hkinjov.117giom@ifi.uio.no>#1/1
X-Deja-AN: 661650527
Original-Date: 23 Aug 2000 12:01:48 -0700
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <8o172s$858$1@penguin.transmeta.com>
References: <fa.gaai08v.f1s71u@ifi.uio.no>
To: linux-ker...@vger.kernel.org
Original-References: <20000823171002.14770.qm...@web207.mail.yahoo.com>
<200008231822.e7NIMrN167...@saturn.cs.uml.edu>
X-Authentication-Warning: palladium.transmeta.com:
mail set sender to n...@transmeta.com using -f
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Transmeta Corporation
Newsgroups: fa.linux.kernel
In article <200008231822.e7NIMrN167...@saturn.cs.uml.edu>,
Albert D. Cahalan <acaha...@cs.uml.edu> wrote:
>
>Ulrich Drepper has repeatedly flamed Linus for not adding the
>features needed for low-overhead POSIX threads. Linus thinks
>the POSIX thread interface is broken, so he won't add the ugly
>bits needed to sanely reach POSIX compliance.
Wrong. I'd be happy to add the bits, it's just that nobody has sent me a
sane patch. People complain a lot, but I haven't seen anything constructive.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: "Andi Kleen" <a...@suse.de>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.irfceuv.oickp5@ifi.uio.no>#1/1
X-Deja-AN: 661657122
Original-Date: Wed, 23 Aug 2000 21:22:02 +0200
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <20000823212202.A26004@gruyere.muc.suse.de>
References: <fa.il6jjov.1j4ion@ifi.uio.no>
To: torva...@transmeta.com (Linus Torvalds)
Original-References: <20000823171002.14770.qm...@web207.mail.yahoo.com>
<Pine.LNX.4.21.0008231824320.1365-100...@saturn.homenet>
<20000823193814.A24...@gruyere.muc.suse.de> <8o16uu$83...@penguin.transmeta.com>
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, Aug 23, 2000 at 11:59:42AM -0700, Linus Torvalds wrote:
> In article <20000823193814.A24...@gruyere.muc.suse.de>,
> Andi Kleen <a...@suse.de> wrote:
> >
> >To solve that it would be very nice to have Mach like continuations in
> >Linux (multiple kernel threads sharing a kernel stack)
>
> Oh, Gods, no.
>
> Continuations are evil. And they don't scale in SMP. Don't even think
> about them.
So you would prefer a two level threads library ?
[you probably agree that it is silly to have java programs with 20 threads
each eating a kernel stack -- and there are not only java programs which
use that wasteful programming style. java programs at least have the
excuse of a stupid API that forces them to do such stuff]
continuations are just a lot of what the two level library would do in user
space put more efficiently into kernel space (like multiplexing poll)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds <torva...@transmeta.com>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/23
Message-ID: <fa.o8prfmv.s4g6bj@ifi.uio.no>#1/1
X-Deja-AN: 661658895
Original-Date: Wed, 23 Aug 2000 12:28:22 -0700 (PDT)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <Pine.LNX.4.10.10008231224540.802-100000@penguin.transmeta.com>
References: <fa.irfceuv.oickp5@ifi.uio.no>
To: Andi Kleen <a...@suse.de>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, 23 Aug 2000, Andi Kleen wrote:
>
> So you would prefer a two level threads library ?
Read as "continuations in user space"? Sure.
It's not that I agree or prefer it, it's just that I don't care at that
point ;)
> [you probably agree that it is silly to have java programs with 20 threads
> each eating a kernel stack -- and there are not only java programs which
> use that wasteful programming style. java programs at least have the
> excuse of a stupid API that forces them to do such stuff]
I suspect the Java run-time had better do a lot of these decisions itself.
I don't think they are all that appropriate decisions to make for the
kernel.
> continuations are just a lot of what the two level library would do in user
> space put more efficiently into kernel space (like multiplexing poll)
I don't think it's an issue of efficiency - you end up doing the work
anyway. It may well be true that some of the interfaces aren't perfect for
Java threads, and maybe that could be improved upon, but I can't say that
I've seen any really convincing arguments for "performance" and "Java"
yet.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Michael Rothwell <rothw...@holly-springs.nc.us>
Subject: Re: SCO: "thread creation is about a thousand times faster than onnative Linux"
Date: 2000/08/23
Message-ID: <fa.ihjcjqv.9h0so6@ifi.uio.no>#1/1
X-Deja-AN: 661660393
Original-Date: Wed, 23 Aug 2000 15:33:35 -0400
Sender: linux-kernel-ow...@vger.kernel.org
Content-Transfer-Encoding: 7bit
Original-Message-ID: <39A4270F.3DF627C4@holly-springs.nc.us>
References: <fa.o8prfmv.s4g6bj@ifi.uio.no>
To: Linus Torvalds <torva...@transmeta.com>
Original-References: <Pine.LNX.4.10.10008231224540.802-100...@penguin.transmeta.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
Linus Torvalds wrote:
>
> On Wed, 23 Aug 2000, Andi Kleen wrote:
> >
> > So you would prefer a two level threads library ?
>
> Read as "continuations in user space"? Sure.
Solaris (and possibly the upcoming BSD threads support)
will map threads onto kernel threads as needed. Provides
better scaling. But it's really a glibc issue. LinuxThreads
author Xavier Leroy (I think) decided to do a 1:1 mapping.
LinuxThreads became the glibc pthreads implementation.
End of story.
Standardized light weight threads would be nice. Does the
kernel evenhave to provide any additional support to make
them possible? Or can the glibc guys just bang them out?
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Subject: Re: SCO: "thread creation is about a thousand times faster than onnative
Date: 2000/08/23
Message-ID: <fa.h240vnv.157cn9t@ifi.uio.no>#1/1
X-Deja-AN: 661678329
Original-Date: Wed, 23 Aug 2000 21:17:10 +0100 (BST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-Id: <E13RgxU-0000eO-00@the-village.bc.nu>
Content-Transfer-Encoding: 7bit
References: <fa.ihjcjqv.9h0so6@ifi.uio.no>
To: rothw...@holly-springs.nc.us (Michael Rothwell)
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
> Solaris (and possibly the upcoming BSD threads support)
> will map threads onto kernel threads as needed. Provides
> better scaling. But it's really a glibc issue. LinuxThreads
> author Xavier Leroy (I think) decided to do a 1:1 mapping.
> LinuxThreads became the glibc pthreads implementation.
People using pthreads arent interested in performance. They are going for
portability at a (high at times) cost.
> Standardized light weight threads would be nice. Does the
> kernel evenhave to provide any additional support to make
> them possible? Or can the glibc guys just bang them out?
The kernel has fast lightweight threading. How you map user space threads and
co-routines onto this is really between the app and libs. In fact I'd argue
strongly that an app _must_ be able to provide its own strategy routine or
some kind of hints to the lib
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: "Andi Kleen" <a...@suse.de>
Subject: Re: SCO: "thread creation is about a thousand times faster than onnative
Date: 2000/08/23
Message-ID: <fa.isvmf6v.p26kh3@ifi.uio.no>#1/1
X-Deja-AN: 661680067
Original-Date: Wed, 23 Aug 2000 22:26:25 +0200
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <20000823222625.A27125@gruyere.muc.suse.de>
References: <fa.h240vnv.157cn9t@ifi.uio.no>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Original-References: <39A4270F.3DF62...@holly-springs.nc.us>
<E13RgxU-0000eO...@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, Aug 23, 2000 at 09:17:10PM +0100, Alan Cox wrote:
> The kernel has fast lightweight threading. How you map user space threads and
> co-routines onto this is really between the app and libs. In fact I'd argue
> strongly that an app _must_ be able to provide its own strategy routine or
> some kind of hints to the lib
I would not call 8K/16K overhead "lightweight" treading.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Tigran Aivazian <tig...@veritas.com>
Subject: Re: SCO: "thread creation is about a thousand times faster than onnative
Date: 2000/08/23
Message-ID: <fa.ld6ti0v.1qncgb3@ifi.uio.no>#1/1
X-Deja-AN: 661680072
Original-Date: Wed, 23 Aug 2000 21:36:16 +0100 (BST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <Pine.LNX.4.21.0008232134050.1069-100000@saturn.homenet>
References: <fa.h240vnv.157cn9t@ifi.uio.no>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
X-Sender: tig...@saturn.homenet
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, 23 Aug 2000, Alan Cox wrote:
> The kernel has fast lightweight threading. How you map user space threads and
> co-routines onto this is really between the app and libs. In fact I'd argue
> strongly that an app _must_ be able to provide its own strategy routine or
> some kind of hints to the lib
Alan, all this userspace stuff is external to the original discussion,
i.e. really irrelevant. The original claim made by Juergen is that native
UW7 lwp are faster than native Linux clone'd tasks. I.e. kernel objects vs
kernel objects comparison. Userspace threads can be fast or slow, I don't
care as long as we discuss the kernel lightweight threads.
And I don't believe that UW7 lwp creation is 1000x faster than Linux
CLONE_VM task creation, until he can prove it.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Subject: Re: SCO: "thread creation is about a thousand times faster than on
Date: 2000/08/23
Message-ID: <fa.h3176nv.131iu9t@ifi.uio.no>#1/1
X-Deja-AN: 661685067
Original-Date: Wed, 23 Aug 2000 21:21:39 +0100 (BST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-Id: <E13Rh1q-0000fi-00@the-village.bc.nu>
Content-Transfer-Encoding: 7bit
References: <fa.lcnji8v.1r7uhj8@ifi.uio.no>
To: tig...@veritas.com (Tigran Aivazian)
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
> I do correct myself - there is one thing in UW7 that is definitely worth
> using under Linux - the VERITAS vxfs journalling filesystem, i.e. ;)
When it becomes open source maybe. Until then I think XFS, Reiserfs etc over
LVM and software raid look way more appealing
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Subject: Re: SCO: "thread creation is about a thousand times faster than
Date: 2000/08/23
Message-ID: <fa.h40b7vv.1446vht@ifi.uio.no>#1/1
X-Deja-AN: 661685080
Original-Date: Wed, 23 Aug 2000 21:35:11 +0100 (BST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-Id: <E13RhEv-0000hG-00@the-village.bc.nu>
Content-Transfer-Encoding: 7bit
References: <fa.ld6ti0v.1qncgb3@ifi.uio.no>
To: tig...@veritas.com (Tigran Aivazian)
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
> And I don't believe that UW7 lwp creation is 1000x faster than Linux
> CLONE_VM task creation, until he can prove it.
If my benching is right he has rather few instructions to make a clone 1000x
faster ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Subject: Re: SCO: "thread creation is about a thousand times faster than onnative
Date: 2000/08/23
Message-ID: <fa.h3vb3vv.143qrht@ifi.uio.no>#1/1
X-Deja-AN: 661685087
Original-Date: Wed, 23 Aug 2000 21:33:54 +0100 (BST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-Id: <E13RhDf-0000h8-00@the-village.bc.nu>
Content-Transfer-Encoding: 7bit
References: <fa.isvmf6v.p26kh3@ifi.uio.no>
To: a...@suse.de (Andi Kleen)
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
> On Wed, Aug 23, 2000 at 09:17:10PM +0100, Alan Cox wrote:
> > The kernel has fast lightweight threading. How you map user space threads and
> > co-routines onto this is really between the app and libs. In fact I'd argue
> > strongly that an app _must_ be able to provide its own strategy routine or
> > some kind of hints to the lib
>
> I would not call 8K/16K overhead "lightweight" treading.
For kernel level threading with the functionality provided it is very light
weight. Don't mix kernel lightweight with 'light weight' in C library
terms which normally means a malloc and filling in a few values to fake
a userspace process context
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds <torva...@transmeta.com>
Subject: Re: SCO: "thread creation is about a thousand times faster than onnative
Date: 2000/08/23
Message-ID: <fa.n94p7tv.7qjgj@ifi.uio.no>#1/1
X-Deja-AN: 661687276
Original-Date: Wed, 23 Aug 2000 13:46:49 -0700 (PDT)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <Pine.LNX.4.10.10008231345310.1015-100000@penguin.transmeta.com>
References: <fa.isvmf6v.p26kh3@ifi.uio.no>
To: Andi Kleen <a...@suse.de>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, 23 Aug 2000, Andi Kleen wrote:
> On Wed, Aug 23, 2000 at 09:17:10PM +0100, Alan Cox wrote:
> > The kernel has fast lightweight threading. How you map user space threads and
> > co-routines onto this is really between the app and libs. In fact I'd argue
> > strongly that an app _must_ be able to provide its own strategy routine or
> > some kind of hints to the lib
>
> I would not call 8K/16K overhead "lightweight" treading.
Oh, and pray tell how much you expect a kernel thread to take?
The memory overhead is negligible. An app that thinks that 16kB/thread is
too much, should not be using kernel threads in the first place. You could
argue that it probably shouldn't be using threads at _all_.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: "Andi Kleen" <a...@suse.de>
Subject: Re: SCO: "thread creation is about a thousand times faster than onnative
Date: 2000/08/23
Message-ID: <fa.iufqguv.qi2k96@ifi.uio.no>#1/1
X-Deja-AN: 661690451
Original-Date: Wed, 23 Aug 2000 22:54:57 +0200
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <20000823225457.A27555@gruyere.muc.suse.de>
References: <fa.n94p7tv.7qjgj@ifi.uio.no>
To: Linus Torvalds <torva...@transmeta.com>
Original-References: <20000823222625.A27...@gruyere.muc.suse.de>
<Pine.LNX.4.10.10008231345310.1015-100...@penguin.transmeta.com>
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, Aug 23, 2000 at 01:46:49PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 23 Aug 2000, Andi Kleen wrote:
>
> > On Wed, Aug 23, 2000 at 09:17:10PM +0100, Alan Cox wrote:
> > > The kernel has fast lightweight threading. How you map user space threads and
> > > co-routines onto this is really between the app and libs. In fact I'd argue
> > > strongly that an app _must_ be able to provide its own strategy routine or
> > > some kind of hints to the lib
> >
> > I would not call 8K/16K overhead "lightweight" treading.
>
> Oh, and pray tell how much you expect a kernel thread to take?
The users do not distingush between kernel thread and thread. They just
want a thread and assume it is lightweight. Linux effectively gives them
only heavy threads currently, which they usually do not need.
(like the "posix programmer
knows the availability of everything, but the cost of nothing", to adapt
a maybe not fitting saying)
> The memory overhead is negligible. An app that thinks that 16kB/thread is
> too much, should not be using kernel threads in the first place. You could
> argue that it probably shouldn't be using threads at _all_.
I argue that actually sometimes, but usually fail. At least I think
if they really want to use threads it should not hurt the rest of the system.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Subject: Re: SCO: "thread creation is about a thousand times faster than onnative
Date: 2000/08/23
Message-ID: <fa.h800onv.174cc9t@ifi.uio.no>#1/1
X-Deja-AN: 661706385
Original-Date: Wed, 23 Aug 2000 22:34:19 +0100 (BST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-Id: <E13RiA9-0000oF-00@the-village.bc.nu>
Content-Transfer-Encoding: 7bit
References: <fa.iufqguv.qi2k96@ifi.uio.no>
To: a...@suse.de (Andi Kleen)
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
> The users do not distingush between kernel thread and thread. They just
> want a thread and assume it is lightweight. Linux effectively gives them
> only heavy threads currently, which they usually do not need.
So take this to glibc-bugs
I belive the phrase we use over here is 'preaching to the converted'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel <r...@conectiva.com.br>
Subject: needed scheduler improvements
(was: Re: SCO: "thread creation is about a thousand times faster than on native Linux")
Date: 2000/08/23
Message-ID: <fa.nql2d9v.jm2pr2@ifi.uio.no>#1/1
X-Deja-AN: 661715424
Original-Date: Wed, 23 Aug 2000 19:05:00 -0300 (BRST)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <Pine.LNX.4.21.0008231900321.23124-100000@duckman.distro.conectiva>
References: <fa.dktiamv.q6a1br@ifi.uio.no>
To: kuz...@ms2.inr.ac.ru
X-Sender: r...@duckman.distro.conectiva
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
On Wed, 23 Aug 2000 kuz...@ms2.inr.ac.ru wrote:
> BTW look into our scheduler, which scans all the list of idle
> processes each time slice, when only one process is running
> really and the rest are deathly dead. 8)
We really should fix this, indeed.
There's also another thing which I'd like our scheduler
to do right. Suppose we have 2 processes running in the
background, calculating stuff (they'll both become low
priority, which is good).
Now one of the processes is halfway it's timeslice and
gets interrupted by something. After that short interruption
Linux continues with the _other_ cpu intensive thread,
blowing the cache and making the system slower than it should
be.
A third issue would be NUMA (and maybe some SMP) scalability.
We may want to have 'local' (per node, or per cpu) run queues
with a less opportunistic thread migration between cpus.
With memory becoming a worse and worse bottleneck, I guess we
should be a bit more careful about using the cache as best as
possible than we are now...
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: "Albert D. Cahalan" <acaha...@cs.uml.edu>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/24
Message-ID: <linux.kernel.200008240402.e7O42DY19302@jupiter.cs.uml.edu>#1/1
X-Deja-AN: 661827575
Approved: n...@nntp-server.caltech.edu
X-To: torva...@transmeta.com (Linus Torvalds)
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
X-Cc: linux-ker...@vger.kernel.org
Newsgroups: mlist.linux.kernel
Linus Torvalds writes:
> Albert D. Cahalan <acaha...@cs.uml.edu> wrote:
>> Ulrich Drepper has repeatedly flamed Linus for not adding the
>> features needed for low-overhead POSIX threads. Linus thinks
>> the POSIX thread interface is broken, so he won't add the ugly
>> bits needed to sanely reach POSIX compliance.
>
> Wrong. I'd be happy to add the bits, it's just that nobody
> has sent me a sane patch. People complain a lot, but I haven't
> seen anything constructive.
Nobody will send you a sane patch without you at least hinting
at what you might like to see. I'm sure many of us would be happy
to write the code, but not under the expectation that it will
be rejected. I wasted quite a bit of my time on the last patch
I sent you, and I'm not about to do that again.
The thread-process mess mostly hits me with procps, which can
not be fixed without kernel changes. I need the kernel to spit
out /proc entries in an order such that threads of a single
process appear next to each other; sorting is not OK to do.
BIG PROBLEM: if the lead thread of a process exits and the PID
gets reused, then the new process has unrelated threads????
Perhaps you could answer this post from March, which dealt with
PID wrap-around, kill(), and the ugly mess in /proc:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0003.3/1289.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds <torva...@transmeta.com>
Subject: Re: SCO: "thread creation is about a thousand times faster than on native Linux"
Date: 2000/08/24
Message-ID: <fa.n4l99tv.nuhgi@ifi.uio.no>#1/1
X-Deja-AN: 661824519
Original-Date: Wed, 23 Aug 2000 21:54:55 -0700 (PDT)
Sender: linux-kernel-ow...@vger.kernel.org
Original-Message-ID: <Pine.LNX.4.10.10008232141430.7800-100000@penguin.transmeta.com>
References: <fa.g88ptgv.1n0k1po@ifi.uio.no>
To: "Albert D. Cahalan" <acaha...@cs.uml.edu>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
On Thu, 24 Aug 2000, Albert D. Cahalan wrote:
>
> Nobody will send you a sane patch without you at least hinting
> at what you might like to see. I'm sure many of us would be happy
> to write the code, but not under the expectation that it will
> be rejected.
Acceptable solution:
- add "tgid" (thread group ID) to "struct task_struct"
- CLONE_PID will leave tgid unchanged.
- non-CLONE_PID will set "tgid" to the same as pid
- get_pid() checks that the new pid is not the tgid of any process.
Basically, the above creates a new "session pid" for the collection of
threads. This is nothing new: the above is basially _exactly_ the same as
p->pgrp and p->session, so it fits quite well into the whole pid notion.
It also means that "current->pid" basically becomes a traditional "thread
ID", while "current->tgid" effectively becomes what pthreads calls a
"pid". Except Linux does it the right way around, ie the same way we've
done sessions and process groups. Because, after all, this _is_ just a
process group extension.
Now, once you have a "tgid" for each process, you can add system calls to
- sys_gettgid(): get the thread ID
- sys_tgkill(): do a pthreads-like "send signal to thread group" (or
extend on the current sys_kill())
Now, the problem is that the thread group kill thing for true POSIX
threads signal behaviour probably has to do some strange magic to get the
pthreads signal semantics right. I don't even know the exact details here,
so somebody who _really_ knows pthreads needs to look long and hard at
this (efficiency here may require that we have a circular list of each
"thread ID group" - ie that we add the proper process pointer list that
gets updated at fork() and exit() so that we can easily walk every process
in the process group list).
Discussion welcome. Basically, it needs somebody who knows pthreads well,
but actually has good taste despite that fact. Such people seem to be in
short supply ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/