>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/