On Fri, May 31, 2002 at 02:02:27AM -0700, Terry Lambert wrote:
[...]
> Bottom line?
>
> I'd like to see one set of uniform semantics.
>
> It really disturbs me that the behaviour of a common flag changes
> for some code, because of a sysctl, but doesn't change for all code
> using the flag.
>
Bosko Milekic wrote:
> Then *you* can set *your* timer to hang to infinity. *I* have
> provided *the* ability to do *that*:
>
> tesla# sysctl -A | grep mbuf_wait
> kern.ipc.mbuf_wait: 32
> tesla# sysctl -w kern.ipc.mbuf_wait=0
>
> (Now the mbuf code will behave in such a way that it
On Tue, May 28, 2002 at 11:36:23PM -0700, Terry Lambert wrote:
> Poul-Henning Kamp wrote:
> > In message <[EMAIL PROTECTED]>, Peter Wemm writes:
> > >As you said, _sleeping_ is the problem. M_WAITOK means "you may sleep if
> > >you like". ie: it is a time bomb waiting for the right low memory
On Wed, May 29, 2002 at 01:04:00PM -0700, Terry Lambert wrote:
> Bosko Milekic wrote:
> > On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote:
> > > Can we get rid of the NULL tests we had to put in when M_WAIT
> > > turned into M_WAITOK?
> >
> > No. What you see as a bad thing other
On Wed, May 29, 2002 at 12:20:20AM -0700, Peter Wemm wrote:
> M_WAIT for mbufs (not malloc) was an alias for M_WAITOK, and M_DONTWAIT
> (also just for mbufs) was an alias for M_NOWAIT.
>
> You call things and either permit them to tsleep() or you do not.
>
> M_NOWAIT to the mbuf m_get*, malloc*
On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote:
> Can we get rid of the NULL tests we had to put in when M_WAIT
> turned into M_WAITOK?
No. What you see as a bad thing others (including me) see as a good
thing. I _want_ to be able to say: "okay, try sleeping; but I realize
th
Bosko Milekic wrote:
> On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote:
> > Can we get rid of the NULL tests we had to put in when M_WAIT
> > turned into M_WAITOK?
>
> No. What you see as a bad thing others (including me) see as a good
> thing. I _want_ to be able to say: "okay,
On 2002-05-29 00:24 -0700, Peter Wemm wrote:
> There is a known bug in UMA where it recurses and calls itself with with
> M_WAITOK even if it was explicitly called with M_NOWAIT set. The bug is
> real and would cause a panic if we actually ran low on memory at that
> point.
Just in case anyone m
On 29-May-2002 Peter Wemm wrote:
> M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means
> "you must not tsleep!". M_WAITOK conversely means that tsleep should be
> called as needed. Things like malloc still can return NULL even with M_WAITOK
> for non-recoverable scenarios.
No,
On Wed, 29 May 2002, Peter Wemm wrote:
> M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means
> "you must not tsleep!". M_WAITOK conversely means that tsleep should be
> called as needed. Things like malloc still can return NULL even with M_WAITOK
> for non-recoverable scenarios
On Wed, 29 May 2002, Peter Wemm wrote:
> Poul-Henning Kamp wrote:
> > Uhm, I'm actually seeing the opposite behaviour as well: after I
> > changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc
> > sleeping...
>
> No, this is a bug in UMA. In certain circumstances, it calls itself
>
On Tue, 28 May 2002, Peter Wemm wrote:
> Richard Wenninger wrote:
> > /usr/src/sys/vm/uma_core.c:1324: could sleep with "UMA lock" locked from
> > /usr/src/sys/vm/uma-core.c:1157
> >
> > Should I be concerned?
>
> Excessively concerned: no. But these are all *real* problems that must
> be fixed.
Terry Lambert wrote:
> Poul-Henning Kamp wrote:
> > In message <[EMAIL PROTECTED]>, Peter Wemm writes:
> > >As you said, _sleeping_ is the problem. M_WAITOK means "you may sleep if
> > >you like". ie: it is a time bomb waiting for the right low memory condit
ion
> > >which will then explode
Terry Lambert wrote:
> Peter Wemm wrote:
> > > I think _sleeping_ is a problem, but allocation with M_WAITOK
> > > shouldn't be, given it's strange definition of "waiting". This
> > > is one of those hacks that John Baldwin was talking about earlier...
> >
> > As you said, _sleeping_ is the prob
Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Peter Wemm writes:
>
> >As you said, _sleeping_ is the problem. M_WAITOK means "you may sleep if
> >you like". ie: it is a time bomb waiting for the right low memory conditio
n
> >which will then explode with a 100% authentic crash
Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Peter Wemm writes:
> >As you said, _sleeping_ is the problem. M_WAITOK means "you may sleep if
> >you like". ie: it is a time bomb waiting for the right low memory condition
> >which will then explode with a 100% authentic crash or lock
Peter Wemm wrote:
> > I think _sleeping_ is a problem, but allocation with M_WAITOK
> > shouldn't be, given it's strange definition of "waiting". This
> > is one of those hacks that John Baldwin was talking about earlier...
>
> As you said, _sleeping_ is the problem. M_WAITOK means "you may sle
In message <[EMAIL PROTECTED]>, Peter Wemm writes:
>As you said, _sleeping_ is the problem. M_WAITOK means "you may sleep if
>you like". ie: it is a time bomb waiting for the right low memory condition
>which will then explode with a 100% authentic crash or lock up.
>
>Pretend it said M_SLEEPO
Terry Lambert wrote:
> Peter Wemm wrote:
> > The bug is that things are calling things like malloc with M_WAITOK when
> > waiting is explicitly not allowed. There are other functions that can
> > tsleep as well that we have not added checks for yet, so this is likely
> > just the tip of the icebe
Peter Wemm wrote:
> The bug is that things are calling things like malloc with M_WAITOK when
> waiting is explicitly not allowed. There are other functions that can
> tsleep as well that we have not added checks for yet, so this is likely
> just the tip of the iceberg. :-(
Why is this a problem
Richard Wenninger wrote:
> This is my first attempt at running "current".
>
> Please forgive if this question is out of line.
>
> After rebuilding everything, my console continually repeats this message:
>
> /usr/src/sys/vm/uma_core.c:1324: could sleep with "UMA lock" locked from
> /usr/src/sy
> On Sun, 5 May 2002, Doug Barton wrote:
> > With yesterday's -current:
> >
> > lock order reversal
> > 1st 0xcc5987a4 DIRHASH (UMA zone) @
> > /usr/Local/src-current/sys/vm/uma_core.c:297
> > 2nd 0xc76c2224 PCPU 256 (UMA cpu) @
> > /usr/Local/src-current/sys/vm/uma_core.c:1630
I see the same
On Sun, 5 May 2002, Doug Barton wrote:
> With yesterday's -current:
>
> lock order reversal
> 1st 0xcc5987a4 DIRHASH (UMA zone) @
> /usr/Local/src-current/sys/vm/uma_core.c:297
> 2nd 0xc76c2224 PCPU 256 (UMA cpu) @
> /usr/Local/src-current/sys/vm/uma_core.c:1630
>
> FYI.
Here's another from
23 matches
Mail list logo
