Re: mem=16MB laptop testing

[Andrew Morton]

William Lee Irwin III <wli@xxxxxxxxxxxxxx> wrote:
>
> So I tried mem=16m on my laptop (stinkpad T21).

Thanks for doing this.  We should try to not suck in this situation.

> (a) The profile buffer requires about a 5MB bootmem allocation;
> 	this near halves MemTotal when used. I refrained from using it,
> 	as otherwise it's a test of mem=8m instead of mem=16m.

OK, so don't boot with `profile=N', yes?

> (b) bootmem allocations aren't adding up; after kernel text, data,
> 	and tracing __alloc_bootmem_core(), there is still about 0.5MB
> 	still missing from MemTotal. I still haven't found where it's
> 	gone. mem_map's bootmem allocation also didn't show up in the
> 	logs, but it should only be 160KB for 16MB of RAM, not 512KB.
> 	Matt Mackall spotted this, too.

Perhaps drop a printk(size) and a dump_stack() into the bootmem allocator,
then postprocess the dmesg output after it's booted?

> (c) mem= no longer bounds the highest physical address, but rather
> 	the sum of memory in e820 entries post-sanitization. This
> 	means a ZONE_NORMAL with about 384KB showed up, with duly
> 	perverse heuristic consequences for page_alloc.c

I don't understand this.  You mean almost all memory was in ZONE_DMA?

"mem=" does not accurately emulate having that much memory.  So a 512M box
booted with "mem=256M" has a different amount of memory from a 256M box
booted with no "mem=" option.  It would be nice to fix that, but I've never
looked into it.

> (d) The system thrashed heavily on boot, allowing the largest mm
> 	to acquire an RSS no larger than about 100KB. This needed
> 	turning /proc/sys/vm/min_free_kb down to 128 to make the
> 	system behave closer to normally. Matt Mackall spotted this.

hrm.  min_free_kbytes is normally 1024.  I'm surprised that the additional
900k made so much difference.  We must be on the hairy edge.

It looks like we need to precalculate/scale min_free_kbytes, yes?

> (e) About 4.8MB are consumed by slab allocations at runtime.
> 	The top 10 slab abusers are:
> 
> inode_cache               840K           840K     100.00%   
> dentry_cache              746K           753K      99.07%   
> ext3_inode_cache          591K           592K      99.84%   
> size-4096                 504K           504K     100.00%   
> size-512                  203K           204K      99.75%   
> size-2048                 182K           204K      89.22%   
> pgd                       188K           188K     100.00%   
> task_struct               100K           108K      92.86%   
> vm_area_struct             93K           101K      92.28%   
> blkdev_requests           101K           101K     100.00%   
> 
> The inode_cache culprit is the obvious butt of many complaints:
> # find /sys | wc -l
> 2656
> 
> ... which accounts for 100% of the 840KB. TANSTAAFL. OTOH, maybe we
> need to learn to do better than pinning dentries and inodes in-core...

I guess not mounting /sys doesn't help here.  It would be nice.  Maybe with
a CONFIG_I_WILL_NEVER_MOUNT_SYSFS we could avoid all those allocations.

> Load control, anyone?

Roger Luethi is working on it; I need to pay some attention to his patch. 
I expect we'll have something for post-2.6.0.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/