On Tue, 30 Jan 2007, Zach Brown wrote:
> +void asys_task_exiting(struct task_struct *tsk)
> +{
> + struct asys_result *res, *next;
> +
> + list_for_each_entry_safe(res, next, &tsk->asys_completed, item)
> + kfree(res);
> +
> + /*
> + * XXX this only works if tsk->fibr
> Isn't that kind of information supposed to be captured in nfs_open_context ?
> Which is associated with the open file instance ...
Or a refcounted struct cred. Which would be needed for strict POSIX thread
semantics likely anyways. But there never was enough incentive to go down
that path and i
On Thu, Feb 01, 2007 at 11:50:06AM -0800, Trond Myklebust wrote:
> On Thu, 2007-02-01 at 16:43 +0530, Suparna Bhattacharya wrote:
> > Wooo ...hold on ... I think this is swinging out of perspective :)
> >
> > I have said some of this before, but let me try again.
> >
> > As you already discovered
On Thu, Feb 01, 2007 at 01:29:41PM -0800, Zach Brown wrote:
> >I want to try it on from a userspace perspective.
>
> Frankly, I'm not sure its ready for that yet. You're welcome to give
> it a try, but it's early enough that you're sure to hit problems
> almost immediately.
I'm counting on
On Thu, Feb 01, 2007 at 02:18:55PM -0800, Zach Brown wrote:
> >Wooo ...hold on ... I think this is swinging out of perspective :)
>
> I'm sorry, but I don't. I think using the EIOCBRETRY method in
> complicated code paths requires too much maintenance cost to justify
> its benefits. We can a
Wooo ...hold on ... I think this is swinging out of perspective :)
I'm sorry, but I don't. I think using the EIOCBRETRY method in
complicated code paths requires too much maintenance cost to justify
its benefits. We can agree to disagree on that judgement :).
- z
-
To unsubscribe from th
Do you have any userspace code that can be used to get started
experimenting
with your fibril based AIO stuff?
I only have a goofy little test app so far:
http://www.zabbo.net/~zab/aio-walk-tree.c
It's not to be taken too seriously :)
I want to try it on from a userspace perspectiv
On Tue, Jan 30, 2007 at 01:39:45PM -0700, Zach Brown wrote:
> sys_asys_submit() is added to let userspace submit asynchronous system calls.
> It specifies the system call number and arguments. A fibril is constructed
> for
> each call. Each starts with a stack which executes the given system ca
On Thu, 2007-02-01 at 16:43 +0530, Suparna Bhattacharya wrote:
> Wooo ...hold on ... I think this is swinging out of perspective :)
>
> I have said some of this before, but let me try again.
>
> As you already discovered when going down the fibril path, there are
> two kinds of accesses to curren
On Wed, Jan 31, 2007 at 11:23:39AM -0800, Zach Brown wrote:
> On Jan 31, 2007, at 9:21 AM, Andi Kleen wrote:
>
> >On Wednesday 31 January 2007 18:15, Zach Brown wrote:
> >>
> >>On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
> >>
> >>>Do you have any numbers how this compares cycle wise to just do
On Jan 31, 2007, at 9:21 AM, Andi Kleen wrote:
On Wednesday 31 January 2007 18:15, Zach Brown wrote:
On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
Do you have any numbers how this compares cycle wise to just doing
clone+syscall+exit in user space?
Not yet, no. Release early, release of
On Wednesday 31 January 2007 18:15, Zach Brown wrote:
>
> On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
>
> > Do you have any numbers how this compares cycle wise to just doing
> > clone+syscall+exit in user space?
>
> Not yet, no. Release early, release often, and all that. I'll throw
> s
On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
Do you have any numbers how this compares cycle wise to just doing
clone+syscall+exit in user space?
Not yet, no. Release early, release often, and all that. I'll throw
something together.
- z
-
To unsubscribe from this list: send the line
Zach Brown <[EMAIL PROTECTED]> writes:
> This finally does something useful with the notion of being able to schedule
> stacks as fibrils under a task_struct. Again, i386-specific and in need of
> proper layering with archs.
>
> sys_asys_submit() is added to let userspace submit asynchronous sys
14 matches
Mail list logo