On Tue, Feb 07, 2017 at 07:02:16PM +0100, Florian Westphal wrote: > > I can't really say anything here because *I* don't expect > it to succeed.
Think about incoming TCP connections, you can't rate-limit that without defeating yourself. > Even with this proposed patch things will eventually fail > on OOM conditions. Exactly. That's the only case where it should fail. Previously it would fail if we cannot allocate a large number of consecutive pages, which can happen even if you have lots of memory left. With my patch it will only fail if it cannot allocate at most two non- consecutive pages, i.e., a real OOM. > Also, such period should be very short until rht has reached > peak size for the workload. How would you know? The rate of insertions could be extremely high. > Also, given that we could easily oversubscribe a table by a factor > of 10 or more while still keeping sane chain lengths I don't > see why thats a problem (also, a 'rht_insert_force' or similar > interface that doesn't do chain length checks makes it > easy to spot places that need/want this behaviour). But you would still have to impose a limit, whether it's 1 or 10. IOW you will still fail insertions at some point even though you have sufficient memory to perform the insertion. > (insecure_elasticity and/or insecure_max_entries come to mind, seems > some of that might not even be needed anymore but I don't have time > right now to investigate). Yes insecure_elasticity is now obsolete and anyone using it should switch over to rhlist. Once nobody uses it then it can be removed. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
