From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 17:58:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E9AFBEB9; Fri, 8 Mar 2013 17:58:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id D211A9C1; Fri, 8 Mar 2013 17:58:20 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 3214E24BCC; Fri, 8 Mar 2013 09:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1362765500; bh=Dn+jTQH/LGIATwl/B193zelYe/wvv+2od4ECzplXHeo=; h=Date:From:Reply-To:To:Subject; b=oD4e/WS+/PVdqD3fcdXxUd4MfO1JhMi2hGXkbHM0U//cZQuH+ExfX5qO6TflGggBL +Uyt97mLxgmCp7/PDZCvMFldouv3jPGUeL91rMF5QuY0MYC35ebQw/ThLUjTh3Ju6L GzSp6k/h7CndTH4opIj3wjiJqDtdMCMARtLOqaQ0= Message-ID: <513A26B9.7060305@delphij.net> Date: Fri, 08 Mar 2013 09:58:17 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD Current , Andriy Gapon Subject: FULL_PREEMPTION X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:58:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I have seen a few posts from Andriy as as well as the PC-BSD default that for desktop systems, kern.sched.preempt_thresh=224 would improve responsiveness. Looking at the code, it seems that this is equivalent to compiling the kernel with FULL_PREEMPTION. The sys/conf/NOTES says, however: # FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel # threads. Its sole use is to expose race conditions and other # bugs during development. Enabling this option will reduce # performance and increase the frequency of kernel panics by # design. If you aren't sure that you need it then you don't. # Relies on the PREEMPTION option. DON'T TURN THIS ON. Despite the possibility of exposing race conditions as well as potentially hurting throughput because of (possibly more) context switching, is it considered as a goal that we should support it? If so, should we enable it on -CURRENT? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJROia5AAoJEG80Jeu8UPuzv7MIAKoBNZyR28E5Wdnj2+IkHXvi Vg9TipTxAWSyCBcuywJEoZUCXZs1f/WbGOrbPQv0iS9AWFt9GZJ+arVsk23hwVdw kRredDAoF4kMR85wo0h8Zl04comNN+pdPNlftCGc4B6J63ysg1m7KlhUAHyXWLW9 lS7wleILiF1HRhggq7qBj4OChgbWUUgUBqf9ZMraLQMyFvfdnktE3OkDBOE1J0zu QgEdAtQ2RL5JkocsqGziq4zWKGjqM60WLQAR/5i8sCP+oQ5qRbIebUpc/GKWY7r8 mAQDwrvKU26pbHSWOkT0Qi9cXw+GGG2vTU6fLh1e0p2QBgzpyXO2TfpkL6kioQA= =xenl -----END PGP SIGNATURE-----