在 2023/2/22 下午5:35, WANG Xuerui 写道:
On 2023/2/22 17:30, Lulu Cheng wrote:
在 2023/2/21 下午9:56, WANG Xuerui 写道:
Hi,
On 2023/2/21 21:03, Lulu Cheng wrote:
在 2023/2/21 下午3:41, Xi Ruoyao 写道:
On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
Like la264 only has 40 effective bits of virtual address space.
I'm OK with the change. But the VA length is configurable
building the
kernel. Is there any specific reason LA264 has to use the 40-bit
configuration, or should we reword the commit message like "for
supporting the configuration with less page table level or smaller
page
size"?
I consulted with my colleagues who are working on the kernel,
it looks like this:
The la264 chip desgn is physically 40-bit virtual address.
User mode and kernel mode each account for half:
User mode : 0x0-0x7f ffff ffff
Kernel mode: 0xffff ff80 0000 0000 -0xffff ffff ffff ffff
The high bit is the sign extension of bit39.
Looking at the comments around the TRY_EMPTY_VM_SPACE definitions,
they all indicate that the guessed range should be "likely free" --
that implies "usable". Given the common VM allocation behavior, we
want TRY_EMPTY_VM_SPACE to point at a reasonably high place in the
VA so it's "likely free".
So IMO the point is, will there be any LoongArch HW in the
foreseeable future, with less than maybe 40 bits of VA? If the
answer is "no" then a TRY_EMPTY_VM_SPACE near the 40-bit VA ceiling
would be appropriate. Otherwise you may have to choose a value near
or even below a 32-bit VA's upper limit: according to the ISA manual
Volume 1, Section 2.1.5, "typical VALEN is in the range of [40,
48]"; also see Section 5.2.3, RDVA can be as large as 8, so the
actual VA space could theoretically be as narrow as 40-8=32 bits.
Yes, I agree with your point of view this is looking for a "likely
free" virtual memory space.
But if I want to support chips with less than 40-bit virtual
addresses, then the value of this macro needs to be set small.
I think setting this value small will increase the probability of
virtual address mapping failure.
Not exactly; in case the TYPE_EMPTY_VM_SPACE address happen to be
occupied, the mmap will still return something else that's nonzero
(consult mmap's man page for details), and will not just blow the
process up straight away.
But...
Chips with less than 40-bit virtual address space are small chips for
embedded use.
The purpose of pch is to make compilation faster, but I think we
rarely compile on embedded systems. So this situation may not be
within our consideration.
Everything makes more sense with this context. Now put these
justification into the commit message (after a little bit of rewording
maybe) and I think we're good to go then ;-)
OK! Thanks!:-)
