From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 21 06:34:31 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF9A11065674; Tue, 21 Sep 2010 06:34:31 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 611C88FC13; Tue, 21 Sep 2010 06:34:31 +0000 (UTC) Received: by yxn35 with SMTP id 35so1934146yxn.13 for ; Mon, 20 Sep 2010 23:34:30 -0700 (PDT) Received: by 10.151.106.12 with SMTP id i12mr9953197ybm.106.1285050869234; Mon, 20 Sep 2010 23:34:29 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id u24sm9751004yba.9.2010.09.20.23.34.25 (version=SSLv3 cipher=RC4-MD5); Mon, 20 Sep 2010 23:34:28 -0700 (PDT) Date: Mon, 20 Sep 2010 20:35:33 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Andriy Gapon In-Reply-To: <4C98500D.5040109@freebsd.org> Message-ID: References: <4C93236B.4050906@freebsd.org> <4C935F56.4030903@freebsd.org> <4C98500D.5040109@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 21 Sep 2010 10:37:46 +0000 Cc: Andre Oppermann , Jeff Roberson , Robert Watson , freebsd-hackers@freebsd.org Subject: Re: zfs + uma X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 06:34:32 -0000 On Tue, 21 Sep 2010, Andriy Gapon wrote: > on 19/09/2010 01:16 Jeff Roberson said the following: >> Additionally we could make a last ditch flush mechanism that runs on each cpu in > > How would you qualify a "last ditch" trigger? > Would this be called from "standard" vm_lowmem look or would there be some extra > check for even more severe memory condition? If lowmem does not make enough progress to improve the condition. Jeff > >> turn and flushes some or all of the buckets in per-cpu caches. Presently that is >> not done due to synchronization issues. It can't be done from a central place. >> It could be done with a callout mechanism or a for loop that binds to each core >> in succession. > > -- > Andriy Gapon >