Hi KyongHo and David, On 07.08.20 09:08, Pekka Enberg wrote: > > > I think having more knowledge of DRAM controller details in the OS > > > would be potentially beneficial for better page allocation policy, so > > > maybe try come up with something more generic, even if the fallback to > > > providing this information is a kernel command line option. On Tue, Aug 18, 2020 at 12:02 PM Cho KyongHo <pullip.cho@xxxxxxxxxxx> wrote: > I don't find if there is a way to deliver detailed DRAM information > through ACPI, ATAG or something similar. But I didn't find. Perhaps that's still the case today then. In the context of this patch, what I am hoping is that we'd turn the "dram_rank_granule" parameter -- even if it's still a manually configured thing -- into an abstraction that we can later extend. IOW, something similar to what the "energy model" (kernel/power/energy_model.c) today is. On Mon, Aug 10, 2020 at 09:32:18AM +0200, David Hildenbrand wrote: > I guess one universal approach is by measuring access times ... not what > we might be looking for :) I don't think it's an unreasonable approach, but measurement accuracy and speed will determine if it's actually practical. There are examples of this kind of approach elsewhere too. For example, MCTOP [1] which aims to provide topology-aware OS abstractions, uses cache latency measurements to infer the topology. 1. https://timharris.uk/papers/2017-eurosys-mctop.pdf Regards, - Pekka
