Hi!
> >>How does that work? Switching between kernel threads requires going into
> >>the kernel, user level thread switches are all done in user mode.
> >>
> >>Do you have some way to change o/s threads w/o going into the kernel?
> >>
> >
> >But going into kernel is not very expensive on
Hi!
How does that work? Switching between kernel threads requires going into
the kernel, user level thread switches are all done in user mode.
Do you have some way to change o/s threads w/o going into the kernel?
But going into kernel is not very expensive on Linux.
On the other
> > On the other side, the overhead you need to add for every single syscall
> > that might block for the M:N threads and the associated complications
> > which make it far harder to conform to POSIX IMHO far outweight the costs
> > of going into the kernel for a context switch.
>
> That really
On Sun, 4 Feb 2007, Jakub Jelinek wrote:
> On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
> > Arjan van de Ven wrote:
> > >>Because user threading can avoid context switches, there will always be
> > >>cases where it will outperform o/s threads for hardware reasons.
> > >
> >
Jakub Jelinek wrote:
On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
Arjan van de Ven wrote:
Because user threading can avoid context switches, there will always be
cases where it will outperform o/s threads for hardware reasons.
actually.. switching from one
On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
> Arjan van de Ven wrote:
> >>Because user threading can avoid context switches, there will always be
> >>cases where it will outperform o/s threads for hardware reasons.
> >
> >actually.. switching from one "real" thread to another
Arjan van de Ven wrote:
Because user threading can avoid context switches, there will always be
cases where it will outperform o/s threads for hardware reasons.
actually.. switching from one "real" thread to another in Linux is not
an actual context switch in the hardware sense... at least
Arjan van de Ven wrote:
Because user threading can avoid context switches, there will always be
cases where it will outperform o/s threads for hardware reasons.
actually.. switching from one real thread to another in Linux is not
an actual context switch in the hardware sense... at least this
On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
Arjan van de Ven wrote:
Because user threading can avoid context switches, there will always be
cases where it will outperform o/s threads for hardware reasons.
actually.. switching from one real thread to another in Linux is
Jakub Jelinek wrote:
On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
Arjan van de Ven wrote:
Because user threading can avoid context switches, there will always be
cases where it will outperform o/s threads for hardware reasons.
actually.. switching from one
On Sun, 4 Feb 2007, Jakub Jelinek wrote:
On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
Arjan van de Ven wrote:
Because user threading can avoid context switches, there will always be
cases where it will outperform o/s threads for hardware reasons.
actually..
On the other side, the overhead you need to add for every single syscall
that might block for the M:N threads and the associated complications
which make it far harder to conform to POSIX IMHO far outweight the costs
of going into the kernel for a context switch.
That really wasn't my
> Because user threading can avoid context switches, there will always be
> cases where it will outperform o/s threads for hardware reasons.
actually.. switching from one "real" thread to another in Linux is not
an actual context switch in the hardware sense... at least this part of
your
Because user threading can avoid context switches, there will always be
cases where it will outperform o/s threads for hardware reasons.
actually.. switching from one real thread to another in Linux is not
an actual context switch in the hardware sense... at least this part of
your argument
Kaz Kylheku wrote:
Evgeniy Polyakov wrote:
I described in details why and how M:N model better, and its drawbacks
include all issues mentioned by Ulrich Drepper, but nevertheless its
advantages are far too superiour than those which can be
provided by 1:1
model.
M:N threading is an
Kaz Kylheku wrote:
Evgeniy Polyakov wrote:
I described in details why and how M:N model better, and its drawbacks
include all issues mentioned by Ulrich Drepper, but nevertheless its
advantages are far too superiour than those which can be
provided by 1:1
model.
M:N threading is an
On Wed, Jan 31, 2007 at 11:28:07PM -0500, Lee Revell ([EMAIL PROTECTED]) wrote:
> On 1/29/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >1. Scheduling fairness.
> >Since kernel does not know about multiple threads behind given process,
> >it can not add it appropriate number of timeslices for
On 1/29/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
1. Scheduling fairness.
Since kernel does not know about multiple threads behind given process,
it can not add it appropriate number of timeslices for execution.
Can be solved either by more tight collaboarion of the userspace and
On Tue, Jan 30, 2007 at 01:16:22PM -0800, Kaz Kylheku ([EMAIL PROTECTED]) wrote:
> Evgeniy Polyakov wrote:
> > I described in details why and how M:N model better, and its drawbacks
> > include all issues mentioned by Ulrich Drepper, but nevertheless its
> > advantages are far too superiour than
On Tue, Jan 30, 2007 at 01:16:22PM -0800, Kaz Kylheku ([EMAIL PROTECTED]) wrote:
Evgeniy Polyakov wrote:
I described in details why and how M:N model better, and its drawbacks
include all issues mentioned by Ulrich Drepper, but nevertheless its
advantages are far too superiour than those
On 1/29/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
1. Scheduling fairness.
Since kernel does not know about multiple threads behind given process,
it can not add it appropriate number of timeslices for execution.
Can be solved either by more tight collaboarion of the userspace and
kernelspace
On Wed, Jan 31, 2007 at 11:28:07PM -0500, Lee Revell ([EMAIL PROTECTED]) wrote:
On 1/29/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
1. Scheduling fairness.
Since kernel does not know about multiple threads behind given process,
it can not add it appropriate number of timeslices for
Evgeniy Polyakov wrote:
> I described in details why and how M:N model better, and its drawbacks
> include all issues mentioned by Ulrich Drepper, but nevertheless its
> advantages are far too superiour than those which can be
> provided by 1:1
> model.
M:N threading is an unnecessary performance
Evgeniy Polyakov, le Tue 30 Jan 2007 12:53:16 +0300, a écrit :
> > You may want to have a look at some existing implementations:
>
> I saw most of them.
> As far as I recall, only PTL (is not shown here) has preemptible
> scheduler. NTL has it too, but is based on different approach.
Marcel has
On Tue, Jan 30, 2007 at 11:24:51AM +0100, Samuel Thibault ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov, le Tue 30 Jan 2007 12:53:16 +0300, a écrit :
> > > You may want to have a look at some existing implementations:
> >
> > I saw most of them.
> > As far as I recall, only PTL (is not shown
On Tue, Jan 30, 2007 at 02:18:17AM +0100, Samuel Thibault ([EMAIL PROTECTED])
wrote:
> Hi,
>
> Evgenity, le Mon 29 Jan 2007 16:47:36 +0100, a écrit :
> > Userspace M-on-N threading model is based on the idea, that when signal
> > is delivered, kernel saves all information related to previous
On Mon, Jan 29, 2007 at 10:40:42AM -0600, Chris Friesen ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >Hello.
> >
> >I'm pleased to announce initial userspace M-on-N threading model
> >implementation (for hackers) called NTL.
>
> If you haven't already, I suggest you look into the
On Mon, Jan 29, 2007 at 10:40:42AM -0600, Chris Friesen ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
Hello.
I'm pleased to announce initial userspace M-on-N threading model
implementation (for hackers) called NTL.
If you haven't already, I suggest you look into the story of NGPT
On Tue, Jan 30, 2007 at 02:18:17AM +0100, Samuel Thibault ([EMAIL PROTECTED])
wrote:
Hi,
Evgenity, le Mon 29 Jan 2007 16:47:36 +0100, a écrit :
Userspace M-on-N threading model is based on the idea, that when signal
is delivered, kernel saves all information related to previous context
On Tue, Jan 30, 2007 at 11:24:51AM +0100, Samuel Thibault ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov, le Tue 30 Jan 2007 12:53:16 +0300, a écrit :
You may want to have a look at some existing implementations:
I saw most of them.
As far as I recall, only PTL (is not shown here) has
Evgeniy Polyakov, le Tue 30 Jan 2007 12:53:16 +0300, a écrit :
You may want to have a look at some existing implementations:
I saw most of them.
As far as I recall, only PTL (is not shown here) has preemptible
scheduler. NTL has it too, but is based on different approach.
Marcel has a
Evgeniy Polyakov wrote:
I described in details why and how M:N model better, and its drawbacks
include all issues mentioned by Ulrich Drepper, but nevertheless its
advantages are far too superiour than those which can be
provided by 1:1
model.
M:N threading is an unnecessary performance hack
Hi,
Evgenity, le Mon 29 Jan 2007 16:47:36 +0100, a écrit :
> Userspace M-on-N threading model is based on the idea, that when signal
> is delivered, kernel saves all information related to previous context
> in stack, so it is possible to find it and replace.
You may want to have a look at some
Evgeniy Polyakov wrote:
Hello.
I'm pleased to announce initial userspace M-on-N threading model
implementation (for hackers) called NTL.
If you haven't already, I suggest you look into the story of NGPT and
also read the NPTL white paper
(http://people.redhat.com/drepper/nptl-design.pdf)
P.S. I'm not subscribed to any of the above lists, please Cc: me in
replies.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello.
I'm pleased to announce initial userspace M-on-N threading model
implementation (for hackers) called NTL.
This is first alpha release, which indeed has bugs and limitations.
Userspace M-on-N threading model is based on the idea, that when signal
is delivered, kernel saves all information
Hello.
I'm pleased to announce initial userspace M-on-N threading model
implementation (for hackers) called NTL.
This is first alpha release, which indeed has bugs and limitations.
Userspace M-on-N threading model is based on the idea, that when signal
is delivered, kernel saves all information
P.S. I'm not subscribed to any of the above lists, please Cc: me in
replies.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Evgeniy Polyakov wrote:
Hello.
I'm pleased to announce initial userspace M-on-N threading model
implementation (for hackers) called NTL.
If you haven't already, I suggest you look into the story of NGPT and
also read the NPTL white paper
(http://people.redhat.com/drepper/nptl-design.pdf)
Hi,
Evgenity, le Mon 29 Jan 2007 16:47:36 +0100, a écrit :
Userspace M-on-N threading model is based on the idea, that when signal
is delivered, kernel saves all information related to previous context
in stack, so it is possible to find it and replace.
You may want to have a look at some
40 matches
Mail list logo
