Messages in this thread | | | Date | Thu, 23 Sep 1999 15:20:23 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] hashtable sizes for icache and dcache |
| |
On Thu, 23 Sep 1999, Ingo Molnar wrote:
>this patch alone indeed is just fixing the symptoms. If such a patch makes
You don't understand the difference between fixing the symptom and fixing the cause of a problem.
I'll try to explain you the difference. Trivial example:
static void call(char * foo) { foo = 2; }
main() { char * foo; foo = malloc(1); fill(foo); }
The fix for the symptom is this:
static void call(char * foo) { if (foo) foo = 2; }
but the fix for the _real_ bug, for the _real_ _source/cause_ of the problem is this:
main() { char * foo; foo = malloc(1); if (!foo) perror("exit"), exit(1); fill(foo); }
AGAIN: with my patch I touched the real source/cause of the problem and not any possible symptom. I really don't follow your "symptom" point. If you are aware of the real meaning of the phrase "fixing the symptom" then it means you are trying to generalize such phrase to take it as proof that I am wrong and you are failing in doing that.
Just for example: in this case fixing the symptom would been something like limiting the number of inodes to 1000. That would have hided the ihash improper size (1000 times too small).
>it into the kernel (by accident, your patch wasnt flagged 'incorrect', it >was flagged as 'look how much performance') then it indeed makes it harder >to get the _real_ patch of DaveM (and/or Chuck) to make it into the >kernel. So your patch actually made things harder. I can see nothing
harder??? A define change _can't_ make harder to replace completly a piece of code.
>we all were waiting for a patch like DaveM's to get proper boot-time hash
_YOU_ were waiting for a patch of DaveM as I know nothing about such a patch (while I remebered about Chuck's works and incidentally Chuck was on the CC list). Maybe I missed the relevant email on l-k from DaveM, if so apologies. Also I don't understand why DaveM duplcated the dcache work as Chuck just did it on l-k.
Also such hastables should have a unfyed interface. All patches I seen are duplicating the same code over and over again. We should instead add a clean interface to alloc memory for hashtable passing as parameter the size of the memory and the ratio beween the memory size and the number of buckets you want for each unit of memory. Also I got convinced over the time for completly hash-unrelated reasons that using GFP is the right/sad thing to do for the hash allocation as initrd and any other possible black/arch similar thing is just messy enough without raw allocations in start_kernel().
>are you using older stepping PPro boxes? [..]
No. And I don't remeber such lines in 2.2.x.
> http://www.redhat.com/~mingo/smp-2.3.18-F8
I given a try to B1 and as far I can tell it worked fine. But I didn't thought to check the spurious line with your patch applyed (I rebooted into another kernel too early). I'll give a try to your latest code in the next days. Thanks.
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |