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 Linu
> > 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 w
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.
> > >
> > >act
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 "r
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
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
> 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 argumen
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 unnecessary
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 e
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
kernelspac
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 th
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 a
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
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 cont
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
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 e
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) es
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
Plea
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
20 matches
Mail list logo
