To be honest, I've been a bit frustrated at how to proceed with PAGG.
Yesterday, we kicked around some ideas to perhaps propose to the
community that implement things other ways.
As far as we can tell, these things are not as efficient as PAGG.
For example, we explored the use of notifier lists that are already
available in the kernel. This implements the callback portion of
PAGG, but not the portion that associates data per-task.
Another co-worker also observed that locking of notifier lists isn't
really provided by the notifier list infrastructure itself - so unless
you're really careful, a module could remove itself from the list
while it's being walked.
Another problem with notifier lists is that it probably would have reduced
performance. Instead of knowing you can "do nothing" if the pagg list
is null per task (and that task is probably already cached on the
machine), you have to walk a notifier list each time. It will possibly
reduce fork performance.
The only reason a pagg-like system using notifier lists would get accepted
is because it uses tools already in the kernel instead of our own setup.
So this part might be attractive to some in the community.
In the past, we had pushed PAGG more for its grouping abilities rather
than calling it something like "task notifier list with data" (or some
slick name that means that). We described it like this somewhat because
the community seems to frown on generic callbacks.
Perhaps the world has changed now. After all, notifier lists are
generic callouts and are in the kernel now... Of course, they aren't
in the fork or exit paths.
All of this is compounded by a lack of support from PAGG's users. We know
various people outside of SGI use PAGG, but they never have stepped up to
say they are users when it counts. If we could have some users, our community
position would be improved.
I think having callouts in fork, exec, and exit are really needed. If you
look at what we do during a fork in the kernel, you can spot a few things
in the generic kernel itself that could use generic callouts or PAGG
instead. It has the potential to reduce, at least a little bit, the
number of calls made in a fork.
At a meeting yesterday, I was asked to look in to implementing Linux Job,
SGI inescapable Job Containers, without using PAGG. Instead, I was asked
to try these notifier lists. Because we don't feel we can get a Job ID
in the task struct, I'll need to implement table lookups to associate
a task with data about the task. After some discussion today, I'm not
sure notifier lists are the answer due to reduced performance and locking
issues.
So what do you think? Should I try to implement a reduced version of PAGG
that uses notifier lists for the callout piece and pagg lists like we have
today for the task associated data? (performance issues, locking issues
with notifier lists). Again, this is only attractive because it uses
tools in the kernel itself.
I thought one idea is I could give PAGG, mostly as-is, one more shot. I
can reduce it to it's bare essentials, perhaps removing some functionality.
I can re-name it to something that better describes what it does, and
try once again to get it accepted by the community of LKML. I thought I'd
start on LSE-tech before LKML to get some ideas. Does this sound like a
good approach?
I'd like to work with this mailing list to try to organize support for
this. If there are PAGG users, and you don't want to see us stop maintaining
PAGG, maybe you could join the discussion so people know the patch is used.
SGI really needs something that is PAGG-like for its open sourced projects
such as Job, CSA, and two open-source but non-pushed projects in-house.
But the community is interested in more than "a patch SGI needs for itself."
If we can't get PAGG in, we'll have to work out other ways to get our
open source projects that use PAGG accepted.
In the end, I think lack of users is the biggest problem with getting
something PAGG-like accepted.
Please let me know if there are other ideas.
|