Re: UMA lock
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 also like to see one set of code, if it can be negotiated between > you and the SLAB allocator guy. N allocators is usually N-1 too many, > IMO. Yes, it was my intention to co-ordinate with JeffR and perhaps in a year from now (once UMA really stabilizes and I get the current backlog in my TODO well, out of the backlog) to take a stab at having the mbuf code use uma for allocations. This is why I delayed any further design work in mb_alloc for the moment. I agree that having fewer allocators is a Good Thing and have considered this with the Good of the Project in mind (as opposed to personal issues, ego, or whatever). :-) In any case, when the time comes to really tackle the issue, we will have to be very very careful. mb_alloc was written in such a way that mbuf allocations are optimized out and that for all common-case allocations, ONE function call is performed for the allocation, not more. I remember initially getting a very hard time from you and the lists on keeping the performance numbers up for mbuf allocations (we are known for having very fast mbuf allocation) and I also recall many nights of performance measurement and data gathering. My observation was that: 1) Getting rid of the large macros and moving to mb_alloc, even with Giant in place, slightly improved overall speed (I still have the data, actually: http://www.freebsd.org/~bmilekic/code/mb_alloc/results.html ) This is particularly the case for i386, where the negative cache effects of those large allocation/free macros was really noticable. 2) Increasing the common-case for allocations and frees to more than one single function call resulted in a noticable [albeit slight] slowdown, in the alpha in particular (unfortunately, something happened with jlemon's alpha stats so the graphs are no longer accessible). This is why I worked hard to place the allocation code in such a way to keep it at at most one function call for the common case. I'd like to maintain this assumption when/if we move to uma in the future. > -- Terry Cheers, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 hang forever >if you call with M_TRYWAIT and cannot allocate anything). > > However, *I* want to be able to do otherwise, because *I* don't agree > with *you*. So *I* will leave my timer to whatever the hell I please > and *I* will require callers to check for NULL in all cases, and > handle the failure appropriately, because that's what good systems do. > If for my particular chunk of code or subsystem, "properly" means > "call panic()," then so be it. But if for my particular subsystem it > happens to be *SOMETHING OTHER THAN CALLING panic()*, I want to be > able to catch that failure and handle it after the wait has timed out. I'm OK with trapping conditions differently. But I think an explicit timer allows for that. I really dislike having different rules for mbuf allocation vs. other allocations. I don't like that options have changed from: o Fail rather than waiting, if you would have to wait o If you have to wait, then wait until you will not fail To: o Fail rather than waiting, if you would have to wait o If you have to wait, then wait until you will not fail, but fail if you know that waiting will do no good I don't mind the new option (which is effectively "TRYWAIT"), but I dislike losing the old option. I know you worked a long time on the mbuf allocator. There was, at one time, an intention to move to a new allocator architecture for everything, based on your work, where your work was advertised as a "proof of concept" (this advertising kept many people from complaining too loudly, at the time, since it wasn't a commitment). Then the slab allocator work came in, and while it has statistics locks and some other locks I'd rather it didn't have (since the idea was to divide up the flow to prevent needing locking, and we ended up locking anyway), it seems to fill the same ecological niche that the work based on your proof of concept work would have been filling. Personally, I use my own mbuf allocator on physical memory that was reserved at boot time, so that it has incredibly lower overhead than either the allocator before your work, the allocator after it, or the slab allocator. I don't expect that it's generally useful (most of you people are not building FreeBSD-based networking hardware, so that approach would not be useful to you, anyway). But that fact that the "proof of concept" was limited to an area where I didn't have to use the code at all, also contributed to my personal lack of loud objection to the code. -- 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 also like to see one set of code, if it can be negotiated between you and the SLAB allocator guy. N allocators is usually N-1 too many, IMO. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 > > >which will then explode with a 100% authentic crash or lock up. > > > > > >Pretend it said M_SLEEPOK instead of M_WAITOK. > > > > 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... > > I'm with Poul on this one, Peter: M_WAITOK doesn't mean what > you think it means: it's doesn't mean tsleep may be called, > and M_NOWAIT doesn't mean tsleep() _won't_ be called, in > practice. With the same amount of time you spent typing up this Email, you could have checked the code and seen that M_WAITOK _does_ mean that tsleep may be called and that, in effect, M_NOWAIT means that tsleep will not be called. If we have cases where tsleep is called and are M_NOWAIT, then that's not good. M_NOWAIT means: "only allowed to block on a mutex." > It's either incredibly badly named, or it's incredibly badly > implemented -- I would argue the latter, actually, since even > if it's completely orthogonal, you're screwed because it means > you have two call conversion systems, without a WITNESS > intersection to detect deadly embraces. 8-(. > > -- Terry -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 me) see as a good > > thing. I _want_ to be able to say: "okay, try sleeping; but I realize > > that sleeping for longer than some reasonable time if I'm not getting > > anything to begin with will probably not get me anything at any point > > so tell me the allocation really failed and give me the opportunity to > > clean up before *I* decide what I want to do." > > Up the operating system's wazoo! > > *We* are the programmers. > > *We* know better than *it* whether it's OK to sleep indefinitely > or not. > > If *we* want the allocation to fail after *some reasonable time*, > then *we will damn well set a timer to "some reasonable time"* to > indicate that fact to the OS. > > If *we* do *not* damn well set a timer, then *we* damn well do not > want it to fail, *we* want it to hang either *until it succeeds* or > *until hell freezes over* or *until we manually enter the kernel > debugger to find out why it is hanging*. 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 hang forever if you call with M_TRYWAIT and cannot allocate anything). However, *I* want to be able to do otherwise, because *I* don't agree with *you*. So *I* will leave my timer to whatever the hell I please and *I* will require callers to check for NULL in all cases, and handle the failure appropriately, because that's what good systems do. If for my particular chunk of code or subsystem, "properly" means "call panic()," then so be it. But if for my particular subsystem it happens to be *SOMETHING OTHER THAN CALLING panic()*, I want to be able to catch that failure and handle it after the wait has timed out. If there is code that still uses M_TRYWAIT with the mbuf allocator and does not check for NULL (I believe there is still some of this), well, then, it will simply page fault immediately after it tries dereferencing the NULL pointer and I'll figure it right out. > All these people are bitching about kludging around something by > changing M_WAITOK to M_NOWAIT. > > The kludge is *already there* in M_WAITOK, whether you want it > or not. > > So bitching about this kluge is meaningless: changing it back to > M_WAITOK won't make the little F'er go away, it will just *hide* > the kludge from people to lazy to read the code all the way down, > and know *why* they have to check for a NULL return from a call > that's *supposed to wait* until it's return will *not* be NULL. > > -- Terry > -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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*, 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. Exactly, with one exception: they are no longer aliases. I had renamed (after some discussion) M_WAIT and M_DONTWAIT in the mbuf code to M_TRYWAIT and M_DONTWAIT, respectively, to avoid confusion and avoid mixing the flags with the malloc() flags. > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 sleeping for longer than some reasonable time if I'm not getting anything to begin with will probably not get me anything at any point so tell me the allocation really failed and give me the opportunity to clean up before *I* decide what I want to do." > -- Terry > "Never solve a vast problem in a half-vast way" -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 sleeping; but I realize > that sleeping for longer than some reasonable time if I'm not getting > anything to begin with will probably not get me anything at any point > so tell me the allocation really failed and give me the opportunity to > clean up before *I* decide what I want to do." Up the operating system's wazoo! *We* are the programmers. *We* know better than *it* whether it's OK to sleep indefinitely or not. If *we* want the allocation to fail after *some reasonable time*, then *we will damn well set a timer to "some reasonable time"* to indicate that fact to the OS. If *we* do *not* damn well set a timer, then *we* damn well do not want it to fail, *we* want it to hang either *until it succeeds* or *until hell freezes over* or *until we manually enter the kernel debugger to find out why it is hanging*. All these people are bitching about kludging around something by changing M_WAITOK to M_NOWAIT. The kludge is *already there* in M_WAITOK, whether you want it or not. So bitching about this kluge is meaningless: changing it back to M_WAITOK won't make the little F'er go away, it will just *hide* the kludge from people to lazy to read the code all the way down, and know *why* they have to check for a NULL return from a call that's *supposed to wait* until it's return will *not* be NULL. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 knowledgeable than me knows that to do about
this, here's something that seems to look like this.
A trace that I got when I ran my kernel with WITNESS for a day or so,
was the following. Note the lines marked with an asterisk that
clearly show (unless I am terribly wrong) that UMA is entered twice,
and the WITNESS check fails the second time.
Debugger("witness_sleep")
Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c02d6500) at Debugger+0x45
witness_sleep(1,0,c02eb711,52c) at witness_sleep+0xf8
* uma_zalloc_arg(c082a640,0,0) at uma_zalloc_arg+0x3e
vm_map_entry_create(c0822000,c5b55150,c69a2000,c0822000,c6424bd4) at
vm_map_entry_create+0x2b
_vm_map_clip_end(c0822000,c5b55150,c69a4000) at _vm_map_clip_end+0x4b
vm_map_delete(c0822000,c69a2000,c69a4000,c69a2000,4) at
vm_map_delete+0x94
vm_map_remove(c0822000,c69a2000,c69a4000,c0321140,1) at
vm_map_remove+0x5b
kmem_free(c0822000,c69a2000,2000,c6424c60,c02818a0) at kmem_free+0x3c
page_free(c69a2000,2000,4) at page_free+0x44
zone_drain(c24f3780) at zone_drain+0x302
zone_foreach(c028159e,c6424d0c,c027f22c,c0321140,1) at
zone_foreach+0x2e
* uma_reclaim(c0321140,1,c02eb4c2,286,c0321140) at uma_reclaim+0x12
vm_pageout_scan(0,c027fcaa,c6424d34,c01a0eaa,0) at
vm_pageout_scan+0x30
vm_pageout(0,c6424d48,c6380a3c,c027fcaa,0) at vm_pageout+0x22d
fork_exit(c027fcaa,0,c6424d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37
db> c
--
Giorgos Keramidas| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | http://www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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, M_WAITOK won't return NULL, it will panic first. :) -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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. malloc() itself can't do this, unless malloc(M_WAITOK) has been broken. Thousands of callers depend on malloc(M_WAITOK) not returning NULL, and malloc.9 still documents this behaviour. You may be thinking of mbuf allocation. It is confusingly different, starting with the no-wait flag being spelled differently (M_NOWAIT). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 M_WAITOK even when it itself was called with M_NOWAIT. Or it could be malloc/zalloc sleeping in another process. malloc(M_NOWAIT) may block and then wait a long time for other processes to release resources. This may involved the other processes sleeping, perhaps even with M_WAITOK malloc()'s. Buggy other processes may take arbitrary long to release their resources. The important points are: - the process that called malloc(M_NOWAIT) holds all the locks that it needs to protect its data structures - the process doesn't sleep itself (since sleeping might involve releasing critical lock(s), e.g., Giant) - all this locking and sleeping doesn't cause deadlock. Sleeping without releasing all locks would be a good way to tempt deadlock, and having malloc(M_NOWAIT) sleep despite being told not to would be a good way to sleep with some locks held. Leaf routines like malloc() can barely know which locks are held, and cannot reasonably know which locks are safe to release. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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. > > Specifically, they are holding locks while calling a function that *might* > tsleep() if memory is low at the time. If it does tsleep, it will panic or > otherwise lead to a deadlock or corruption. > > The fact that they've gone largely unnoticed until now means that it is not > an urgent problem (which is why it is a warning), but if you run really low > of memory you will find out just how serious it is. I had checks for calling malloc() with M_WAITOK at a nonzero ipl and found too many problems to notice, so I usually kept the checks turned off. (I still have the checks, but they are no-ops in -current). Most of the problems seem to involve booting and networking code. The socket locking changes in -current seem to have addressed a few of these. > 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. :-( In -current, msleep() could easily check whether it is called with a lock except the expected one (Giant or mtx). Similar ipl-based checks are impossible because it is almost mandatory to sleep it a nonzero ipl to prevent races: s = splfoo(); while ((foo_p->state & FOO_READY) == 0) tsleep(...); // code that depends on foo being ready splx(s); Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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% authentic crash or lock up.
> > >
> > >Pretend it said M_SLEEPOK instead of M_WAITOK.
> >
> > 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...
>
> I'm with Poul on this one, Peter: M_WAITOK doesn't mean what
> you think it means: it's doesn't mean tsleep may be called,
> and M_NOWAIT doesn't mean tsleep() _won't_ be called, in
> practice.
No, it is exactly what it means, eg:
if (!(flags & M_NOWAIT))
KASSERT(curthread->td_intr_nesting_level == 0,
("malloc(M_WAITOK) in interrupt context"));
tsleep() in interrupt context is the kiss-of-death. M_NOWAIT means
"you must not call tsleep!", which is what I have been saying all along.
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.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: UMA 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 means "you may sleep if > > you like". ie: it is a time bomb waiting for the right low memory conditi on > > which will then explode with a 100% authentic crash or lock up. > > > > Pretend it said M_SLEEPOK instead of M_WAITOK. > > M_WAIT became M_WAITOK. Unless M_SLEEPOK becomes M_SLEEP, > I don't think it really matters: it's not going to wait > indefinitely, like you'd want it to, so eventually, it's > going to time out. > > You might get some big latencies along with some kernel > printf's about inverted locks, but it shouldn't end up > being fatal, like a real blocking wait would be, right? > > Or has M_WAITOK gone back to meaning M_WAIT, instead of > M_WAIT_IF_YOU_FEEL_LIKE_IT_OTHERWISE_MAKE_ME_CHECK_FOR_NULL > again? > > Can we get rid of the NULL tests we had to put in when M_WAIT > turned into M_WAITOK? Umm, Terry, have you looked at the code? We *only* have two wait states - M_NOWAIT and M_WAITOK. I dont care what it was ages ago, but in recent history we have a single flag boolean flag. M_WAITOK = 0x00, M_NOWAIT = 0x01. In spite of having two names, it is really a single bit where M_WAITOK != M_NOWAIT. 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*, 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. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 up. > > > >Pretend it said M_SLEEPOK instead of M_WAITOK. > > 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 M_WAITOK even when it itself was called with M_NOWAIT. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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. > > > >Pretend it said M_SLEEPOK instead of M_WAITOK. > > 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... I'm with Poul on this one, Peter: M_WAITOK doesn't mean what you think it means: it's doesn't mean tsleep may be called, and M_NOWAIT doesn't mean tsleep() _won't_ be called, in practice. It's either incredibly badly named, or it's incredibly badly implemented -- I would argue the latter, actually, since even if it's completely orthogonal, you're screwed because it means you have two call conversion systems, without a WITNESS intersection to detect deadly embraces. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA 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 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 instead of M_WAITOK. M_WAIT became M_WAITOK. Unless M_SLEEPOK becomes M_SLEEP, I don't think it really matters: it's not going to wait indefinitely, like you'd want it to, so eventually, it's going to time out. You might get some big latencies along with some kernel printf's about inverted locks, but it shouldn't end up being fatal, like a real blocking wait would be, right? Or has M_WAITOK gone back to meaning M_WAIT, instead of M_WAIT_IF_YOU_FEEL_LIKE_IT_OTHERWISE_MAKE_ME_CHECK_FOR_NULL again? Can we get rid of the NULL tests we had to put in when M_WAIT turned into M_WAITOK? -- Terry "Never solve a vast problem in a half-vast way" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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 instead of M_WAITOK. 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... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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. :-( > > Why is this a problem? M_WAITOK does not mean that it will wait > indefinitely, even though you'd think it would mean that, given > the name... > > 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 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 instead of M_WAITOK. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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? M_WAITOK does not mean that it will wait indefinitely, even though you'd think it would mean that, given the name... 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... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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-core.c:1157 > > Should I be concerned? Excessively concerned: no. But these are all *real* problems that must be fixed. Specifically, they are holding locks while calling a function that *might* tsleep() if memory is low at the time. If it does tsleep, it will panic or otherwise lead to a deadlock or corruption. The fact that they've gone largely unnoticed until now means that it is not an urgent problem (which is why it is a warning), but if you run really low of memory you will find out just how serious it is. 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. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock order reversal
> 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 "shutdown -r now". -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock order reversal
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 yesterday's current. I get this when running savecore: lock order reversal 1st 0xcc614524 PIPE (UMA zone) @ /usr/src/sys/vm/uma_core.c:530 2nd 0xc082a9a4 PCPU PV ENTRY (UMA cpu) @ /usr/src/sys/vm/uma_core.c:1630 -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
