9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: [9fans] pc *kernelpercent improvement
Date: Fri, 16 Apr 2010 10:46:37 -0400	[thread overview]
Message-ID: <938095881ad5430643c47765d1a61c31@kw.quanstro.net> (raw)

with some nic drivers (myricom) requiring a vast amount of
buffer space, and the general pc split between user space
and kernel space on a 4gb machine giving only 71mb to
the kernel (1.6%), i find it necessary to set *kernelpercent
on a few machines that have 3-4 nics.  unfortunately, the
kernel is just too smart to allow me to set *kernelpercent
and applies (imho) too much logic, generally defeating
my settings.

this patch allows one to set *kernelprecent to anything
"reasonable".  reasonable means that kernel memory will
fit in the available virtual memory at or above KZERO.
this, kernel memory is capped at 256MB for the standard
KZERO of 0xf0000000.   but if one had KZERO set to
0x80000000, kernel memory would be capped at 2gb.
naturally, the lowest possible KZERO while maintaining
pci(e) space and user memory would be 0x20000000.  but
i haven't been that brave.  i have only tested 0x30000000.

if *kernelpercent is not set, then the logic is unchanged
from before.

/n/sources/plan9//sys/src/9/pc/main.c:397,405 - main.c:397,408
  		 * page list in imagereclaim just takes too long.
  		 */
  		if(kpages > (64*MB + conf.npage*sizeof(Page))/BY2PG){
- 			kpages = (64*MB + conf.npage*sizeof(Page))/BY2PG;
+ 			if(p == nil){
+ 				kpages = (64*MB + conf.npage*sizeof(Page))/BY2PG;
+ 				kpages += (conf.nproc*KSTACK)/BY2PG;
+ 			}else if(kpages > (ulong)-KZERO)
+ 				kpages = (ulong)-KZERO;
  			conf.nimage = 2000;
- 			kpages += (conf.nproc*KSTACK)/BY2PG;
  		}
  	} else {
  		if(userpcnt < 10) {

one thing that could save quite a bit of buffer space for
most drivers that keep a private pool would be a function
allocbpool(uint cnt, uint size, uint align, void (*free)(Block*)).
if size%align < align you can save cnt*(align - size%align) - align
bytes by allocating the buffers seperately from the Block contents,
in large allocations.  or packing the Block header carefully in the slop.
(in addition to Pool overhead.)

for cnt=512, size=16k and align=4k (myricom needs
a power-of-two buffer and has a 9k mtu) this is
	512*(4k - 0) - 4k = 2mb - 4096b (25%).
for cnt=1024, size=12k and align=4k (82563), this is 4mb (25%).
for 4 or 6 interfaces, this really starts to add up.

- erik



                 reply	other threads:[~2010-04-16 14:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=938095881ad5430643c47765d1a61c31@kw.quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).