Re: New PAGG patch for 2.6.10, new functionality

Sounds worth doing.  I'll have a new patch tomorrow (or I hope to).

Thanks!

On Wed, 12 Jan 2005 [email protected] wrote:

> On Tue, Jan 11, 2005 at 09:11:25AM -0600, Erik Jacobson wrote:
> > Just to make sure I understand --
> >
> > You'd use this in case you want to be notified about each task but you
> > don't necessarily want paggs allocated for each task as you have no
> > desire to group them.  Is that right?
>
> Yes.
>
> >
> > If so, I just didn't think of that use.  I thought people who wanted the init
> > function would also want pagg associations.  Could a person who wants
> > notification of all processes use something like
> > for_each_process/for_each_task instead?
>
> I see. (I'm not sure what you mean by using
> for_each_process/for_each_task for all processes though).
>
> I had the impression that the only difference between init and attach
> was that init served to catch all existing tasks and attach all tasks
> during a fork.
>
> As for skipping pagg associations, my thought was that there might be
> users who would choose to skip a task simply because that task did not
> interest him based on some set criteria.  Some of the existing tasks
> in the system at the time of the user's registration could fall under
> the category of being skipped.  For example, "do not do a pagg
> association for all real time tasks in both init and attach".  If only
> attach allowed for associations to be skipped then users would not be
> able to apply their criteria for existing tasks.
>
> >
> > So is the reason you suggest this just to be consistent like you said in
> > your note?   Or is there a use you had in mind that I didn't think of?
>
> I'm not sure - perhaps I wasn't clear enough earlier. Does the above
> make my reasoning clearer?
>
> >
> > One thing I'd say is that it isn't possible to be fully consistent with
> > attach anyway.  If the init function pointer fails, it isn't like we can
> > propegate the error to fork like we do in attach. And I doubt we'd want to
> > kill the running task :)
>
> Absolutely ;) Full consistency isn't possible.  I was only thinking
> about skipping pagg associations.  A failure during init would have to
> be different to a failure in attach.  Hence the explanation of what
> happens with a <0 error return: the registration function fails but
> the task is not killed.
>
>   <0 Error which is propagated back to copy_process so
>      the registration function fails completely.
>
>   =0 success, attach to same container as parent
>
>   >0 success, but don't attach to a container
>
> >
> > Let me know your thoughts on this...
>
> Thanks for listening,
> --
> 		Kingsley
>

--
Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota