Messages in this thread | | | Date | Tue, 21 Sep 2010 20:48:28 +0200 | Subject | Re: [PATCH 03/10] jump label v11: base patch | From | "Andi Kleen" <> |
| |
>> Doesn > > I suppose you were missing a 't'.
Sorry sentence was eaten (I had to type it twice because the webmail thingy eat it first try and probably didn't finish it second time). I did not doubt your trace point number :)
What I meant is that the number of trace points does not really matter much for binary search, unless you're going to gigantic numbers. 100 is still searched in only a few tries.
What matters is just how many tables you need to walk and that only scales with the number of modules, not the number of trace points.
for ( each module ) binary search in section
Advantage: no additional memory, no setup code other than a simple sort, less code overall.
Also most modules are small so a binary search try is likely very fast.
The methology is also long proven for *_user() exception handling and always worked well here.
>> The only time you add one is when you load a module, right? When you do >> that you only sort the section of the new module. > > And on removing a module.
On removing you simply free the module table, no real work to do.
> Perhaps it can be cleaned up. But I have no issues with it now, and > using a hash (basic data structures 101) is not where the complexity > comes in.
Hash tables are not complex in themselves, but all the code to maintain them still adds up. I think considerable parts of the new code were simply that. IMHO that can be done simpler at no real loss of functionality or performance.
-Andi
| |