On 3/6/07, Ralf Baechle [EMAIL PROTECTED] wrote:
Price question: why would this patch make a difference under VMware? :-)
Moving the struct pcnet32_private from the GFP_DMA32 init_block to the
GFP_KERNEL netdev allocation may be a win even on systems where
GFP_DMA32 is normally cached, because
On 3/7/07, Ralf Baechle [EMAIL PROTECTED] wrote:
GFP_* flags have no influence on caching or prefetching.
The zone modifier flags (like GFP_DMA) can in principle affect the
cache/prefetch policy, since they affect what physical address range
the memory is allocated from. I don't know whether
On 3/6/07, Ralf Baechle [EMAIL PROTECTED] wrote:
This small change btw. delivers about ~ 3% extra performance on a very
slow test system.
Has this change been tested / benchmarked under VMWare? pcnet32 is
the (default?) virtual device presented by VMWare Workstation, and
that's probably a
On 3/3/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Btw, you could try to implement something you have written above to show
its merits, so that it would not be an empty words :)
Before I implement, I design. Before I design, I analyze. Before I
analyze, I prototype. Before I prototype, I
On 3/4/07, David Miller [EMAIL PROTECTED] wrote:
From: Michael K. Edwards [EMAIL PROTECTED]
Before I implement, I design. Before I design, I analyze. Before I
analyze, I prototype. Before I prototype, I gather requirements.
How the heck do you ever get to writing ANYTHING if you work
On 3/2/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Thank you for this report. (Still avoiding cache misses studies, while they
obviously are the limiting factor)
1) The entire point of going to a tree-like structure would be to
allow the leaves to age out of cache (or even forcibly evict them)
On 2/22/07, David Miller [EMAIL PROTECTED] wrote:
From: Michael K. Edwards [EMAIL PROTECTED]
Date: Wed, 21 Feb 2007 13:15:51 -0800
it had better be a 2-left hash with a compact
overflow pool for the rare case of second collision.
Just like Evgeniy, you should do your research too
On 22 Feb 2007 18:49:00 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The rehash-every-10-minutes detail is theoretically unnecessary,
but does cover the case where a would-be attacker *does* get a chance
to look at a machine, such as by using routing delays to measure the
effectiveness of a
Look, Evgeniy. Eric and I may be morons but davem is not. He's
telling you, again and again, that DoS attacks do happen, that to
survive them you need for the distribution of tuples within hash
buckets to vary unpredictably from system to system and boot to boot,
and that XOR hash does not
On 2/20/07, David Miller [EMAIL PROTECTED] wrote:
Actually someone (I think it was Evgeniy in fact) made such
comparisons and found in his studies that not only does the current
ehash xor hash function distribute about as well as jenkins, it's
significantly cheaper to calculate :-)
However,
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Jenkins _does_ have them, I showed tests half a year ago and in this
thread too. Actually _any_ hash has them it is just a matter of time
to find one.
I think you misunderstood me. If you are trying to DoS me from
outside with a hash
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
And here are another ones which produce the same hash value.
Of course searching for pair for jhash('jhash is broken')
will require more steps, but it is doable.
That means that if attacker has a full control over one host, it can
create a
All right, Eric, you and me so clevvah, let's embarrass our own selves
designing this thing in public instead of picking on poor Evgeniy.
Which would you rather RCU, a 2-left hash or a splay tree? 2-left
hash gets you excellent occupation fraction before the first real
collision, so you can be
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
How I like personal insults - it is always fun to read about myself from
people who never knew me :)
On this occasion, I did not set out to insult you. I set out to
suggest an explanation for why cooler and grayer heads than mine are
not
On 2/20/07, Michael K. Edwards [EMAIL PROTECTED] wrote:
Correct. That's called a weak hash, and Jenkins is known to be a
thoroughly weak hash. That's why you never, ever use it without a
salt, and you don't let an attacker inspect the hash output either.
Weak in a cryptographic sense
On 19 Feb 2007 13:04:12 +0100, Andi Kleen [EMAIL PROTECTED] wrote:
LRU tends to be hell for caches in MP systems, because it writes to
the cache lines too and makes them exclusive and more expensive.
That's why you let the hardware worry about LRU. You don't write to
the upper layers of the
A better data structure for RCU, even with a fixed key space, is
probably a splay tree. Much less vulnerable to cache eviction DDoS
than a hash, because the hot connections get rotated up into non-leaf
layers and get traversed enough to keep them in the LRU set. But I am
not a data structures
On 2/18/07, Michael K. Edwards [EMAIL PROTECTED] wrote:
... Much less vulnerable to cache eviction DDoS
than a hash, because the hot connections get rotated up into non-leaf
layers and get traversed enough to keep them in the LRU set.
Let me enlarge on this a bit. I used to work
18 matches
Mail list logo
