Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Jan 2000 22:39:50 -0500 (EST)
From:      Bosko Milekic <bmilekic@dsuper.net>
To:        Warner Losh <imp@village.org>
Cc:        Peter Jeremy <peter.jeremy@alcatel.com.au>, Darren Reed <avalon@coombs.anu.edu.au>, freebsd-security@FreeBSD.ORG
Subject:   Re: kernel panic's still due to mbuf problems. 
Message-ID:  <Pine.OSF.4.05.10001232227090.17210-100000@oracle.dsuper.net>
In-Reply-To: <200001240214.TAA47946@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 23 Jan 2000, Warner Losh wrote:

>In message <00Jan24.125351est.115220@border.alcanet.com.au> Peter Jeremy writes:
>: This subject has been discussed regularly and so far, no-one has
>: managed to produce a solution which does not entail a significant
>: performance hit.  It's generally accepted that the current behaviour
>: is undesirable and if you have real solution to offer, I'm sure
>: it'll be gratefully accepted.
>
>I'm working on that...
>

  Well, then. Would you be willing to share on exactly what aspect you're
  working on? I'm presently designing/writing a quasi-load balancing system
  for local processes. The idea will probably result in a `mbufd' kernel
  thread/daemon which will work with a list to which processes which have
  opened (a) socket(s) will be hung off of. Each entry in the list will
  build its own "horizontal" socket list. As this all grows, when mbufs
  and clusters become significantly limited, the thread would be woken and
  would close sockets belonging to certain processes, thus resulting in
  flushing the sockbuf space for the socket in question. In this situation,
  a system will have to be devised where the load is spread out evenly,
  therefore not permitting a single process to hold on to mbufs or
  mclusters for too long, when something else needs it.

  Remember, this would only be triggered when *low* in network memory
  resources. A wise administrator would ensure that sockbuf limiting is in
  place anyway, and this would be a last-hope solution (better than just
  killing processes off). More discussion will have to be done for what
  concerns the clean closure of the sockets, obviously. I already have the
  x-y lists and the thread written, but the main and most significant
  portion of the work still remains to be designed/written (aside from all
  the gory performance details for what concerns searching and tinkering
  with the x-y lists above).

  Now, if you're writing something else, I'd be very curious to hear about
  it, since it can (and probably will) affect whatever I'm already playing
  with -- if you don't mind. :-)

  -Bosko.

--
 Bosko Milekic
 Email:  bmilekic@dsuper.net




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.05.10001232227090.17210-100000>