On 2/14/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
My opinion of this whole thread is that it implies that our thread creation
and/or context switch is too slow. If that is the case, improve those
elements first. At least some of those optimizations have to be done in
hardware on x86, whil
On Wed, 14 Feb 2007, Benjamin LaHaise wrote:
> On Wed, Feb 14, 2007 at 03:17:59PM -0800, Davide Libenzi wrote:
> > > That's an incorrect assumption. Every task/thread in the system has FPU
> > > state associated with it, in part due to the fact that glibc has to
> > > change
> > > some of the
On Wed, Feb 14, 2007 at 03:17:59PM -0800, Davide Libenzi wrote:
> > That's an incorrect assumption. Every task/thread in the system has FPU
> > state associated with it, in part due to the fact that glibc has to change
> > some of the rounding mode bits, making them different than the default fr
On Wed, 14 Feb 2007, Benjamin LaHaise wrote:
> On Wed, Feb 14, 2007 at 01:06:59PM -0800, Davide Libenzi wrote:
> > Bear with me Ben, and let's follow this up :) If you are in the middle of
> > an MMX copy operation, inside the syscall, you are:
> >
> > - Userspace, on task A, calls sys_async_exe
On Wed, Feb 14, 2007 at 01:06:59PM -0800, Davide Libenzi wrote:
> Bear with me Ben, and let's follow this up :) If you are in the middle of
> an MMX copy operation, inside the syscall, you are:
>
> - Userspace, on task A, calls sys_async_exec
>
> - Userspace in _not_ doing any MMX stuff before t
On Wed, 14 Feb 2007, Benjamin LaHaise wrote:
> On Wed, Feb 14, 2007 at 12:14:29PM -0800, Davide Libenzi wrote:
> > I think you may have mis-interpreted my words. *When* a schedule would
> > block a synco execution try, then you do have a context switch. Noone
> > argue that, and the code is clea
On Wed, Feb 14, 2007 at 12:14:29PM -0800, Davide Libenzi wrote:
> I think you may have mis-interpreted my words. *When* a schedule would
> block a synco execution try, then you do have a context switch. Noone
> argue that, and the code is clear. The sys_async_exec thread will block,
> and a newl
On Wed, 14 Feb 2007, Benjamin LaHaise wrote:
> On Wed, Feb 14, 2007 at 11:45:23AM -0800, Davide Libenzi wrote:
> > Sort of, except that the whole thing can complete syncronously w/out
> > context switches. The real point of the whole fibrils/syslets solution is
> > that kind of optimization. The
On Wed, Feb 14, 2007 at 11:45:23AM -0800, Davide Libenzi wrote:
> Sort of, except that the whole thing can complete syncronously w/out
> context switches. The real point of the whole fibrils/syslets solution is
> that kind of optimization. The solution is as good as it is now, for
Except that Y
On Wed, 14 Feb 2007, Benjamin LaHaise wrote:
> On Wed, Feb 14, 2007 at 09:52:20AM -0800, Davide Libenzi wrote:
> > That'd be, instead of passing a chain of atoms, with the kernel
> > interpreting conditions, and parameter lists, etc..., we let gcc
> > do this stuff for us, and we pass the "clet"
On Wed, Feb 14, 2007 at 09:52:20AM -0800, Davide Libenzi wrote:
> That'd be, instead of passing a chain of atoms, with the kernel
> interpreting conditions, and parameter lists, etc..., we let gcc
> do this stuff for us, and we pass the "clet" :) pointer to sys_async_exec,
> that exec the above
On Wed, 14 Feb 2007, Russell King wrote:
> Let me spell it out, since you appear to have completely missed my point.
>
> At the moment, SKIP_TO_NEXT_ON_STOP is specified to jump a "jump a full
> syslet_uatom number of bytes".
>
> If we end up with a system call being added which requires more th
On Wed, Feb 14, 2007 at 11:50:39AM +0100, Ingo Molnar wrote:
> * Russell King <[EMAIL PROTECTED]> wrote:
> > On Tue, Feb 13, 2007 at 03:20:42PM +0100, Ingo Molnar wrote:
> > > +Arguments to the system call are implemented via pointers to arguments.
> > > +This not only increases the flexibility of
* Russell King <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 13, 2007 at 03:20:42PM +0100, Ingo Molnar wrote:
> > +Arguments to the system call are implemented via pointers to arguments.
> > +This not only increases the flexibility of syslet atoms (multiple syslets
> > +can share the same variable for
On Tue, Feb 13, 2007 at 03:20:42PM +0100, Ingo Molnar wrote:
> +Arguments to the system call are implemented via pointers to arguments.
> +This not only increases the flexibility of syslet atoms (multiple syslets
> +can share the same variable for example), but is also an optimization:
> +copy_uato
On Tue, 13 Feb 2007, Davide Libenzi wrote:
> > > I can understand that chaining syscalls requires variable sharing, but
> > > the majority of the parameters passed to syscalls are just direct
> > > ones. Maybe a smart method that allows you to know if a parameter is a
> > > direct one or a poin
On Tue, 13 Feb 2007, Ingo Molnar wrote:
>
> * Davide Libenzi wrote:
>
> > > +The Syslet Atom:
> > > +
> > > +
> > > +The syslet atom is a small, fixed-size (44 bytes on 32-bit) piece of
> > > +user-space memory, which is the basic unit of execution within the syslet
> > > +frame
* Davide Libenzi wrote:
> > +The Syslet Atom:
> > +
> > +
> > +The syslet atom is a small, fixed-size (44 bytes on 32-bit) piece of
> > +user-space memory, which is the basic unit of execution within the syslet
> > +framework. A syslet represents a single system-call and its argu
Wow! You really helped Zach out ;)
On Tue, 13 Feb 2007, Ingo Molnar wrote:
> +The Syslet Atom:
> +
> +
> +The syslet atom is a small, fixed-size (44 bytes on 32-bit) piece of
> +user-space memory, which is the basic unit of execution within the syslet
> +framework. A syslet rep
19 matches
Mail list logo
