Re: Limit on max_entries of CPU_ARRAY_MAP
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: Limit on max_entries of CPU_ARRAY_MAP
- From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
- Date: Tue, 30 Jan 2018 17:21:26 -0800
- In-reply-to: <CAC1LvL0UYWbmSbNKww_aO-QyrJ9MhZg_kTu-9GgzUU=87irQtQ@mail.gmail.com>
- References: <1517003922.24241.10.camel@regit.org> <CAC1LvL1Ap80X=S5WWcFXqjCAgWocxMrW95cZiYy-8_qk45dGWQ@mail.gmail.com> <CAH3MdRWtFMbagXwZWYyFTP_pEb3k6bLX3ZZt_TfWBFHx2Z5mOg@mail.gmail.com> <CAC1LvL0UYWbmSbNKww_aO-QyrJ9MhZg_kTu-9GgzUU=87irQtQ@mail.gmail.com>
- User-agent: NeoMutt/20170421 (1.8.2)
On Mon, Jan 29, 2018 at 11:00:27AM -0800, Zvi Effron wrote:
> Would it make sense to increase that limit for 64-bit systems? All of
> the comments on why that limit exists that I saw mentioned that
> userspace wouldn't be able to access all of the elements if it were
> bigger. But on a 64-bit system, shouldn't userspace be able to access
> more than 4GB?
What is the _real_ use case for more than 4Gbyte maps?
So far I've seen only one such case that had use to map-in-map
as a workaround to grow the total map size to ~20Gbyte,
but it eventually it was scaled down because at such sizes
performance was bad.
[Index of Archives]
[Linux Networking Development]
[Fedora Linux Users]
[Linux SCTP]
[DCCP]
[Gimp]
[Yosemite Campsites]