[Cbe-oss-dev] [RFC 4/5] spufs: add kernel support for spu task
Benjamin Herrenschmidt
benh at kernel.crashing.org
Thu Jun 14 08:55:48 EST 2007
> good point in theory, but I can't think of an easy way to do it
> without adding complexity to the scheduler.
That's why binding them might actually make sense...
> My idea on this is that the combined amount of object code on the SPU should
> be small enough that you can simply keep it all in one module. If it
> ever grows too large to fit into local store simultaneously, we can use
> the overlay mechanism that is present in recent gcc versions.
But that means that your AES, RC5 etc... crypto and your RAID6 code
would have to all be in a single kernel module, which sucks.
> I know that you prefer to be able to build modules independent of each
> other, so that enabling one module does not require rebuilding the kernel
> or another module, but IMHO that goal is unrealistic anyway and I would
> not sacrifice simplicity for it.
Where did you smoke that one ? It seems pretty simple on the contrary...
It's not like linking SPU code was hard :-) We should look more closely
at what SPURS does for jobs though... does it require the whole set of
jobs used for a given gang to have been linked together at application
build time or does it do it dynamically ?
Ben.
More information about the cbe-oss-dev
mailing list