Re: [Lse-tech] [patch - RFC] simple task notifier support

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Tue, 2006-05-02 at 11:33 +0200, Jes Sorensen wrote:
> Matt Helsley wrote:
> > On Mon, 2006-05-01 at 14:33 -0700, Chandra Seetharaman wrote:
> >>> Yes, however thats adding 24 bytes per task on a 64 bit platform or 12
> >>> bytes per task on a 32 bit platform. Compared to the overhead of running
> >>> many fixed callouts and the number of other data structures in the task
> >>> struct which are rarely used, this really isn't worth counting.
> > 
> > 	I would disagree with that. 24 bytes per task per module interested in
> > the task. If you have 2000 tasks and 10 modules interested in every task
> > that's 469K of memory for the notifier blocks system compared to 0.25K
> > of memory for the global notifier blocks. Whereas the latter can fit in
> > cache memory at many levels, the former cannot. Also, I think doing the
> > 0.25K on a per-cpu basis is also quite reasonable if scalability turns
> > out to be a problem with a global notifier chain.
> 
> The cache argument really doesn't make sense, if you have 2000 tasks,
> it's unlikely that they are all running on the same CPU at the same
> time.

	If it's smaller there's a better chance it will remain in the cache. If
it's 2000 times smaller there's a much better chance it will remain in
cache.

> However the global chain is going to bite if you have 2000 tasks on a
> system and you have them put into groups of an average of 3-4 per group,
> in which case you end up with quite a large table to traverse to find
> out what to do when getting the callout for a random task not to mention
> the additional locking involved in that.

	You're assuming linear search. You could use hashing. Or radix trees.
Or rbtrees. etc. You have lots of options here. That said, I agree with
your point below, so this point of argument is moot. :)

> Anyway it seems very clear that we are trying to solve two different
> problems, both have merit but they are not replacements for each other.
> 
> Jes

	I agree.

Cheers,
	-Matt Helsley