Richard Hilditch wrote:
I am having problems with failing to get memory on a system using LiS
(2.18.0 plus our patches which are close to 2.19.0) under stress. It
looks like each call to allocb maps down to a kmalloc call with
memory type GFP_ATOMIC.
Obviously this is useful if the message is required in interrupt
context but a large part of our Streams code is not running in
interrupt context.
What is the background to this?
Could we consider changing so that for instance if we called allocb
with BPRI_HI it used GFP_ATOMIC and otherwise used GFP_KERNEL?
Dave would be the better one to provide the background, but looking
at current code:
I see know reason why you couldn't add in what you suggest. No LiS
code holds a lock (and therefore can't handle a sleep) while calling
the associated routines. The fix will take a bit of code change
since the routine that does the kmalloc call doesn't know the
priority used to allocate the header or message block.
Having said that, I don't think we could put this into the standard
LiS code base. First, we couldn't rely on ISRs (and routines
which might hold a lock) using BPRI_HI. Second, it goes
against what's documented for other Streams implementations (that
allocb() won't sleep). I'd be afraid of breaking others' drivers.
Note that you'd have to review your own drivers to see if they
hold any locks when they call allocb() or putctl1() with a
lower priority.
Steve
------------------------------------------------------------------------
Steve Schefter phone: +1 705 725 9999 x26
The Software Group Limited fax: +1 705 725 9666
642 Welham Road, email: [EMAIL PROTECTED]
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com
