Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp840544imu; Mon, 5 Nov 2018 09:31:41 -0800 (PST) X-Google-Smtp-Source: AJdET5fKWMfRK2mJeu0QG53oOz2LvlgUfegeLixUQycNXOeZUzcA0EEAS7dZZzu2es2PKDHrTNmG X-Received: by 2002:a17:902:6801:: with SMTP id h1-v6mr22780691plk.177.1541439101915; Mon, 05 Nov 2018 09:31:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541439101; cv=none; d=google.com; s=arc-20160816; b=qHmZtwP3CNlzrsy+iNQ70J/eZtOBWKSPRJjL3QVhqpznBC3NhtTmc0iCDJnUyBsiKP VXcGc2JftBT03nDV4Kf8NjWCei+YEYtgp9SQeqEZNPsSSmX5xQmvYEHYHjgQOm1TUbOz gseOGzVk6n8iOeSOhmKXgbHzchQQPcLmRmnICeHF6prj/eL3CYWgDvwRH7ciRwlusQ1l 0RjQGaRh+kGDW/pnOEf/FwXC0tInENt7+let8+xdht+jbotLNmIRsZdWUK5CLaqMLgmD AlYYcLQUy8T8C4uHhr7y7TWxTmtEb8Po5hJuA+ij9gdhG8O4Rwt0z7lF/NOAY0Oz+o73 RDsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=4ClvvTHLyoYdZ3KCX6hmvEmSAOAiC6wowqETr5am8os=; b=DVrcl2XX/vcF4oJSxhA8IzBPlerNG1MaqMMNZ+NmsDbDhrVcUdG0Fcbb8GhpXSxY1e xagkKoVfQ6EgUFDmDSEpmTaV2VFK17nKKPCr15tXhAGBufm+uO/UOGTJEAQTad211iuy flTsdU4qc9Jr0E7jNERHHlJm5FLCRwUpCXfvMck0yZcw4bcRKSXIYwokpRFE85jmhe1A trJpQB1gVUOMtK7PE4Rptg7YoaMBBBp7c7ltMqDv6gn3AN+OLt3GJHt8sNn6BmVX6rtT kM91BKjn5R4vY3oOKOVvAxz7uDb2Rlt8fKF+eGtkE9tudEMvv0Tu4A2zCvg/nGWc871T mb+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t18-v6si39557205pgj.144.2018.11.05.09.31.26; Mon, 05 Nov 2018 09:31:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730131AbeKFCuQ (ORCPT + 99 others); Mon, 5 Nov 2018 21:50:16 -0500 Received: from mx2.suse.de ([195.135.220.15]:33860 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729692AbeKFCuP (ORCPT ); Mon, 5 Nov 2018 21:50:15 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 33867B0B7; Mon, 5 Nov 2018 17:29:32 +0000 (UTC) Date: Mon, 5 Nov 2018 18:29:31 +0100 From: Michal Hocko To: Daniel Jordan Cc: linux-mm@kvack.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, aarcange@redhat.com, aaron.lu@intel.com, akpm@linux-foundation.org, alex.williamson@redhat.com, bsd@redhat.com, darrick.wong@oracle.com, dave.hansen@linux.intel.com, jgg@mellanox.com, jwadams@google.com, jiangshanlai@gmail.com, mike.kravetz@oracle.com, Pavel.Tatashin@microsoft.com, prasad.singamsetty@oracle.com, rdunlap@infradead.org, steven.sistare@oracle.com, tim.c.chen@intel.com, tj@kernel.org, vbabka@suse.cz Subject: Re: [RFC PATCH v4 00/13] ktask: multithread CPU-intensive kernel work Message-ID: <20181105172931.GP4361@dhcp22.suse.cz> References: <20181105165558.11698-1-daniel.m.jordan@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181105165558.11698-1-daniel.m.jordan@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 05-11-18 11:55:45, Daniel Jordan wrote: > Michal, you mentioned that ktask should be sensitive to CPU utilization[1]. > ktask threads now run at the lowest priority on the system to avoid disturbing > busy CPUs (more details in patches 4 and 5). Does this address your concern? > The plan to address your other comments is explained below. I have only glanced through the documentation patch and it looks like it will be much less disruptive than the previous attempts. Now the obvious question is how does this behave on a moderately or even busy system when you compare that to a single threaded execution. Some numbers about best/worst case execution would be really helpful. I will look closer later. -- Michal Hocko SUSE Labs