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,
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
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
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
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
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
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.
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
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
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
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
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:
>
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_uatom()
* 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 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 syslet
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 than
the
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 under
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 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 You
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 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 newly
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 clear. The
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 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 from
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 rounding
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, while
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
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
> > >
* 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
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
From: Ingo Molnar <[EMAIL PROTECTED]>
Add Documentation/syslet-design.txt with a high-level description
of the syslet concepts.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
Documentation/syslet-design.txt | 137
From: Ingo Molnar [EMAIL PROTECTED]
Add Documentation/syslet-design.txt with a high-level description
of the syslet concepts.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
Documentation/syslet-design.txt | 137
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
* Davide Libenzi davidel@xmailserver.org 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
On Tue, 13 Feb 2007, Ingo Molnar wrote:
* Davide Libenzi davidel@xmailserver.org 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
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 pointer to one?
39 matches
Mail list logo
