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
that
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 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 others (including
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 condition
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 will
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.
I'd
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_SLEEPOK
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 sleep if
you
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 up.
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 or lock
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 problem. M_WAITOK
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 with a 100%
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
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
with
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 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 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 more
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, try
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/sys/vm/uma-core.c:1157
Should I be concerned
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/sys/vm/uma
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?
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 iceberg. :-(
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.
--
We have known freedom's price. We have shown freedom's power.
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
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 one when I run
This is probably a known lock order reversals, but
I haven't seen it reported on the mailing list.
lock order reversal
1st 0xc403d720 PCPU 4096 (UMA cpu) @ /usr/src/sys/vm/uma_core.c:1179
2nd 0xc403d664 4096 (UMA zone) @ /usr/src/sys/vm/uma_core.c:614
3rd 0xc082a720 PCPU KMAP ENTRY (UMA cpu)
26 matches
Mail list logo
