On Thu, Apr 12, 2012 at 08:42:25AM -0400, Kevin O'Connor wrote:
On Thu, Apr 12, 2012 at 08:11:13AM +0300, Gleb Natapov wrote:
On Wed, Apr 11, 2012 at 08:34:13PM -0400, Kevin O'Connor wrote:
On Wed, Apr 11, 2012 at 04:27:57PM +0300, Gleb Natapov wrote:
Hi Kevin,
Is there a reason why drive_s structures are allocated from f-segment?
The data is accessed from 16bit mode, so it must be in the first meg. Only malloc_low() and malloc_fseg() provide data in this range. Putting it in the f-segment has the advantage of not taking space away from the OS (malloc_low uses the 9-segment) and the code generated from f-segment accesses is slightly better (it can use %cs).
Each virtio disk allocates huge VQ from low memory. Allocating relatively small drive_s should not take much additional memory. Besides OS has enough memory as is. Some OSes do not use low memory at all since many buggy bioses write there during SMM or resume.
Yes - but it's not nice for older OSs. One of things I'd like to do is move malloc_low allocations from the 9-segment to the e-segment. Then the code can allocate what ever it wishes.
The space for f-segment allocations are barely sufficient for bios tables.
There's plenty of space in the f-segment. All the 32bit init code that is relocated is given back to malloc_fseg - that's typically about 20k.
But f-seg allocation does not take advantage of that space.
It does use it - see addSpace() call in pmm.c:malloc_fixupreloc().
It uses only CONFIG_MAX_BIOSTABLE bytes which is 2048 currently. Is it OK to grow this?
It could be increased, but I don't see why it would need to.
For the problem I described below, but you are saying it is already fixed in upstream.
Also, most of the bios tables are placed in high memory(malloc_high).
The problem is with MPC table which has to be in low memory for older Linux kernel and it has entry for each socket. When people use large smp values boot starts to fail since bios can't init desks.
This should have been fixed in SeaBIOS commit 8b9137d29 (which was in v1.6.3). There's plenty of space for the mptable now.
Ah, I think I checked with rhel6 seabios which does not have this commit. I'll recheck with upstream seabios.
It may be worthwhile to put a cap on the size of the mptable in the f-segment - do something similar to what's currently done for smbios - if the mptable size is greater than some size then put it in high memory. This should work on the premise that anyone using a setup sophisticated enough to require a very large mptable will likely have a recent Linux kernel.
I wouldn't trust people on this :)
-- Gleb.