[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPNVh5eKO7sdEQpCo+YELhGE2koKiDatg-toaHjd4BfvZWUKXg@mail.gmail.com>
Date: Tue, 9 Nov 2021 08:31:53 -0800
From: Peter Oskolkov <posk@...gle.com>
To: Barry Song <21cnbao@...il.com>
Cc: posk@...k.io, Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>, linux-api@...r.kernel.org,
Paul Turner <pjt@...gle.com>, Ben Segall <bsegall@...gle.com>,
Andrei Vagin <avagin@...gle.com>, Jann Horn <jannh@...gle.com>,
Thierry Delisle <tdelisle@...terloo.ca>
Subject: Re: [PATCH v0.8 0/6] sched,mm,x86/uaccess: implement User Managed
Concurrency Groups
Hi Barry,
[...]
>
> Do you have a real workload or an example application using UMCG?
>
[...]
A google-internal variant of UMCG kernel patches is used extensively
to enable user-space scheduling of heterogeneous work items. The main
use case is services that need to ensure user isolation; in addition,
latency vs throughput workloads served by the same service are also
well addressed by user-space schedulers.
For example, a DBMS needs to ensure that one "hungry" user does not
adversely affect other well-behaved users; but at the same time if the
overall load is relatively low, users are allowed to go ahead and
consume as much CPU as possible, as long as this does not affect other
users negatively.
Services that treat their work uniformly, and care only about raw
throughput, usually do not benefit from custom user-space scheduling
that UMCG, or similar, enables.
Thanks,
Peter
Powered by blists - more mailing lists