From owner-freebsd-current Wed May 29 0:20:29 2002 Delivered-To: freebsd-current@freebsd.org Received: from evilpete.dyndns.org (12-232-26-46.client.attbi.com [12.232.26.46]) by hub.freebsd.org (Postfix) with ESMTP id 18F5337B404 for ; Wed, 29 May 2002 00:20:21 -0700 (PDT) Received: from overcee.wemm.org ([10.0.0.3]) by evilpete.dyndns.org (8.11.6/8.11.6) with ESMTP id g4T7KK162788 for ; Wed, 29 May 2002 00:20:20 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 89F16380A; Wed, 29 May 2002 00:20:20 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Richard Wenninger , current@FreeBSD.ORG Subject: Re: UMA lock In-Reply-To: <3CF475E3.8925781A@mindspring.com> Date: Wed, 29 May 2002 00:20:20 -0700 From: Peter Wemm Message-Id: <20020529072020.89F16380A@overcee.wemm.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message