On Thu, 24 Oct 2024 at 00:00, NeilBrown <neilb@xxxxxxx> wrote: > > > Currently per-client DRC slot limits (for v4.1+) are calculated when the > client connects, and they are left unchanged. So earlier clients can > get a larger share when memory is tight. > > The heuristic for choosing a number includes the number of configured > server threads. This is problematic for 2 reasons. > 1/ sv_nrthreads is different in different net namespaces, but the > memory allocation is global across all namespaces. So different > namespaces get treated differently without good reason. > 2/ a future patch will auto-configure number of threads based on > load so that there will be no need to preconfigure a number. This will > make the current heuristic even more arbitrary. > > NFSv4.1 allows the number of slots to be varied dynamically - in the > reply to each SEQUENCE op. With this patch we provide a provisional > upper limit in the EXCHANGE_ID reply which might end up being too big, > and adjust it with each SEQUENCE reply. I have some concerns here: 1. How should this be tested? You are adding a random element to the test matrix, without an option to manually set a fixed value, or disable it. At least there should be a hook in /proc to set the number of DRC slots, so CI can simulate changes. 2. How do you provide backwards compatibility to clients which do not implement the number of slots adjustments per SEQUENCE op, or implement it wrong? Just claim "its the NFSv4.1 standard, and legacy clients should burn&die" is not an option, otherwise AWS&co will try a Jeanne d'Arc-style punishment on those responsible 3. How do you handle changes in memory, e.g. memory hotplug, or changes in mem assigned to the VM running the nfsd? Is swap space counted too? Finally: 4. Windows until Windows Server 2003 (leaked source code can be googled) had this kind of memory autoscaling for SMB. Each Windows release before Server 2003 had increasingly more complex code, with increasingly unpleasant curses in the source comments about unexpected and unwanted side effects. After Windows Server 2003 this whole machinery was yanked out, because it was much more harmful to customers than any savings in memory consumptions could ever bring. Why do you want to try to bring the same nightmarish experiment to the NFSv4 world, after Microsoft failed so horribly? Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
