From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933869AbdKBPYy (ORCPT ); Thu, 2 Nov 2017 11:24:54 -0400 Received: from mail-pg0-f41.google.com ([74.125.83.41]:47602 "EHLO mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933418AbdKBPYx (ORCPT ); Thu, 2 Nov 2017 11:24:53 -0400 X-Google-Smtp-Source: ABhQp+T37U3O4r9YvOhMhvwpO3/+6nZYxEh40KyLJA3b6A+hKp9T9af6VrjD4S+lBsfWfMWGlpADKA== Message-ID: <1509636290.20221.3.camel@gmail.com> Subject: Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall) From: Shawn Paul Landden To: Colin Walters Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Date: Thu, 02 Nov 2017 08:24:50 -0700 In-Reply-To: <1509565071.2650718.1158454064.7E910622@webmail.messagingengine.com> References: <20171101053244.5218-1-slandden@gmail.com> <1509549397.2561228.1158168688.4CFA4326@webmail.messagingengine.com> <1509565071.2650718.1158454064.7E910622@webmail.messagingengine.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2017-11-01 at 15:37 -0400, Colin Walters wrote: > threading is limited doing sync()/fsync() and gethostbyname() async. > > But languages with a GC tend to at least use a background thread for > that, > and of course lots of modern userspace makes heavy use of > multithreading > (or variants like goroutines). > > A common pattern though is to have a "main thread" that acts as a > control > point and runs the mainloop (particularly for anything with a GUI). > That's > going to be the thing calling prctl(SET_IDLE) - but I think its idle > state should implicitly > affect the whole process, since for a lot of apps those other threads > are going to > just be "background". > > It'd probably then be an error to use prctl(SET_IDLE) in more than > one thread > ever? (Although that might break in golang due to the way goroutines > can > be migrated across threads) > > That'd probably be a good "generality test" - what would it take to > have > this system call be used for a simple golang webserver app that's > e.g. > socket activated by systemd, or a Kubernetes service? Or another > really interesting case would be qemu; make it easy to flag VMs as > always > having this state (most of my testing VMs are like this; it's OK if > they get > destroyed, I just reinitialize them from the gold state). > > Going back to threading - a tricky thing we should handle in general > is when userspace libraries create threads that are unknown to the > app; > the "async gethostbyname()" is a good example. To be conservative > we'd > likely need to "fail non-idle", but figure out some way tell the > kernel > for e.g. GC threads that they're still I realize none of this is a problem because when prctl(PR_SET_IDLE, PR_IDLE_MODE_KILLME) is set the *entire* process has declared itsself stateless and ready to be killed.