Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1646352
| From | Pasha Tatashin <pasha.tatashin@oracle.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [v4 1/1] mm: Adaptive hash table scaling |
| Date | 2017-05-21 15:00 +0200 |
| Message-ID | <tJyCL-7To-35@gated-at.bofh.it> (permalink) |
| References | <tJg37-4h7-5@gated-at.bofh.it> <tJg37-4h7-7@gated-at.bofh.it> <tJotH-1hi-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Andi, Thank you for looking at this. I mentioned earlier, I would not want to impose a cap. However, if you think that for example dcache needs a cap, there is already a mechanism for that via high_limit argument, so the client can be changed to provide that cap. However, this particular patch addresses scaling problem for everyone by making it scale with memory at a slower pace. Thank you, Pasha On 05/20/2017 10:07 PM, Andi Kleen wrote: > Pavel Tatashin <pasha.tatashin@oracle.com> writes: > >> Allow hash tables to scale with memory but at slower pace, when HASH_ADAPT >> is provided every time memory quadruples the sizes of hash tables will only >> double instead of quadrupling as well. This algorithm starts working only >> when memory size reaches a certain point, currently set to 64G. >> >> This is example of dentry hash table size, before and after four various >> memory configurations: > > IMHO the scale is still too aggressive. I find it very unlikely > that a 1TB machine really needs 256MB of hash table because > number of used files are unlikely to directly scale with memory. > > Perhaps should just cap it at some large size, e.g. 32M > > -Andi > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> >
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[v4 0/1] mm: Adaptive hash table scaling Pavel Tatashin <pasha.tatashin@oracle.com> - 2017-05-20 19:10 +0200
[v4 1/1] mm: Adaptive hash table scaling Pavel Tatashin <pasha.tatashin@oracle.com> - 2017-05-20 19:10 +0200
Re: [v4 1/1] mm: Adaptive hash table scaling Andi Kleen <andi@firstfloor.org> - 2017-05-21 04:10 +0200
Re: [v4 1/1] mm: Adaptive hash table scaling Pasha Tatashin <pasha.tatashin@oracle.com> - 2017-05-21 15:00 +0200
Re: [v4 1/1] mm: Adaptive hash table scaling Andi Kleen <andi@firstfloor.org> - 2017-05-21 18:40 +0200
Re: [v4 1/1] mm: Adaptive hash table scaling Michael Ellerman <mpe@ellerman.id.au> - 2017-05-22 08:20 +0200
Re: [v4 1/1] mm: Adaptive hash table scaling Michal Hocko <mhocko@kernel.org> - 2017-05-22 11:30 +0200
Re: [v4 1/1] mm: Adaptive hash table scaling Pasha Tatashin <pasha.tatashin@oracle.com> - 2017-05-22 15:20 +0200
Re: [v4 1/1] mm: Adaptive hash table scaling Michal Hocko <mhocko@kernel.org> - 2017-05-22 15:40 +0200
Re: [v4 1/1] mm: Adaptive hash table scaling Pasha Tatashin <pasha.tatashin@oracle.com> - 2017-05-22 15:50 +0200
csiph-web