From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 1 14:36:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DC9E0932; Fri, 1 Mar 2013 14:36:06 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5C28E; Fri, 1 Mar 2013 14:36:06 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id db10so2907879veb.23 for ; Fri, 01 Mar 2013 06:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JnLxKJIIldMy8zxEUIzhiAGGrGK/gPTyFat7CbXnGD0=; b=EbH2wfVdkKRYY6JrcO8Ogbb9jUVwnrD9Zj6X7PEGEP/3YWKmgq7VCiCf33L+/Qjr7d yZLey5iShIOk00xqYMKmjHntfDvyo2zDaGvRdD/E1KlTp7Q7oNqqGBJy/lVeH8uFFuLk jXM9rsyBupF4jiMZrnFsYwgl7fEAu7rTgSl7lF3tDTjEOEqNyvqFZ9Hoophd6orcpbjt d7wnhVCOLDQu90hHQ5ADWmZ+jyqmJnue7/a7ekozs0oxtUuhA/BB535K6cX7qYSLhr34 KRmXd2o2g05ErkETLoFNjwy4tL+AX2NWGaqi7HbI8RUrTSWczJfq4GYClsBQE5n0aUk5 no2Q== MIME-Version: 1.0 X-Received: by 10.59.11.67 with SMTP id eg3mr4236056ved.31.1362148565554; Fri, 01 Mar 2013 06:36:05 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.220.34.203 with HTTP; Fri, 1 Mar 2013 06:36:05 -0800 (PST) In-Reply-To: <5130B224.8000600@FreeBSD.org> References: <5130B224.8000600@FreeBSD.org> Date: Fri, 1 Mar 2013 15:36:05 +0100 X-Google-Sender-Auth: uP12gW5Mwo7ZR-N4fkjntBgum54 Message-ID: Subject: Re: memory allocation in spinlock context From: Davide Italiano To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 14:36:06 -0000 On Fri, Mar 1, 2013 at 2:50 PM, Andriy Gapon wrote: > > I am trying to understand if it is possible to allow memory allocations (M_NOWAIT, > of course) in a spinlock context. > I do not see any obvious architectural obstacles. > But the fact that all of the uma locks, system map lock, object locks, page queue > locks and so on are regular mutexes makes it impossible to allocate memory without > violating the fundamental lock ordering rules. > > Could all of the above mentioned locks potentially be converted to spin mutexes? > (And that seems to be a large nasty change) AFAIK they're suitable for particular uses and not in general. For example if the critical section is short, spinning rather than sleeping could avoid a potential context switches, increasing performances. OTOH has the disadvantage of wasting time that could be used in other activities. So, IMHO, if such a change need to be adopted, ti should be pondered/profiled more than a bit, and I doubt it could be used for the wide class of locks you mentioned. > Are there any alternative possibilities? > Is there anything that prevent you to drop the lock, perform the allocation in a reliable fashion (M_WAITOK) and try to reacquire the lock later on? > BTW, currently we have at least one place where a memory allocation of this kind > is done stealthily (and thus dangerously?). ACPI resume code must execute > AcpiLeaveSleepStatePrep with interrupts disabled and ACPICA code performs memory > allocations in that code path. Since the interrupts are disabled by means of > intr_disable(), witness(9) and similar are completely oblivious of the fact. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Thanks, -- Davide