On Fri, Jul 04, 2025 at 08:08:41PM +0900, Shashank Balaji wrote:
> Current cpu.max tests (both the normal one and the nested one) are broken.
>
> They setup cpu.max with 1000 us quota and the default period (100,000 us).
> A cpu hog is run for a duration of 1s as per wall clock time. This correspo
y attributed to the scheduler, deferring the panic gives
> sched_ext an opportunity to provide additional debug info when ejecting
> the current scheduler. Also, handling the event more gracefully allows
> us to potentially recover the system instead of incurring additional
> down time.
&
On Tue, Jun 17, 2025 at 03:36:52PM +0200, Michal Koutný wrote:
> Michal Koutný (4):
> selftests: cgroup_util: Add helpers for testing named v1 hierarchies
> selftests: cgroup: Add support for named v1 hierarchies in test_core
> selftests: cgroup: Optionally set up v1 environment
> selftests
adjusting the test_memcontrol selftest
> to fix these test failures.
>
> Waiman Long (2):
> selftests: memcg: Allow low event with no memory.low and
> memory_recursiveprot on
> selftests: memcg: Increase error tolerance of child memory.current
> check in test_memc
On Sun, Mar 30, 2025 at 05:52:39PM -0400, Waiman Long wrote:
> There is a possible race between removing a cgroup diectory that is
> a partition root and the creation of a new partition. The partition
> to be removed can be dying but still online, it doesn't not currently
> participate in checking
Hello,
On Thu, Apr 03, 2025 at 03:34:05PM +0200, Michal Koutný wrote:
> On Tue, Apr 01, 2025 at 09:49:45PM -1000, Tejun Heo wrote:
> > On Sun, Mar 30, 2025 at 05:52:39PM -0400, Waiman Long wrote:
> ...
> > > Add a new cpuset_css_killed() function to reset the partition s
Hello,
On Thu, Apr 03, 2025 at 09:24:34PM -0400, Waiman Long wrote:
...
> The simple and naive fix of changing the operator to ">", however,
> changes the memory reclaim behavior which can lead to other failures
> as low events are needed to facilitate memory reclaim. So we can't do
> that withou
Hello, Waiman.
On Mon, Mar 31, 2025 at 11:12:06PM -0400, Waiman Long wrote:
> The problem is the RCU delay between the time a cgroup is killed and is in a
> dying state and when the partition is deactivated when cpuset_css_offline()
> is called. That delay can be rather lengthy depending on the cu
On Sun, Mar 30, 2025 at 05:52:48PM -0400, Waiman Long wrote:
> The current cgroup directory layout for running the partition state
> transition tests is mainly suitable for testing local partitions as
> well as with a mix of local and remote partitions. It is not that
> suitable for doing extensive
Hello,
On Sun, Mar 30, 2025 at 05:52:39PM -0400, Waiman Long wrote:
...
> One possible way to fix this is to iterate the dying cpusets as well and
> avoid using the exclusive CPUs in those dying cpusets. However, this
> can still cause random partition creation failures or other anomalies
> due to
On Wed, Feb 26, 2025 at 07:50:57AM +0100, Andrea Righi wrote:
> Add a selftest to validate the behavior of the NUMA-aware scheduler
> functionalities, including idle CPU selection within nodes, per-node
> DSQs and CPU to node mapping.
>
> Signed-off-by: Andrea Righi
Applied to sched_ext/for-6.15
On Wed, Feb 05, 2025 at 12:59:53AM +0530, Bharadwaj Raju wrote:
> The script uses non-POSIX features like `[[` for conditionals and hence
> does not work when run with a POSIX /bin/sh.
>
> Change the shebang to /bin/bash instead, like the other tests in cgroup.
>
> Signed-off-by: Bharadwaj Raju
On Thu, Dec 05, 2024 at 02:51:01PM -0500, Waiman Long wrote:
> Isolated CPUs are not allowed to be used in a non-isolated partition.
> The only exception is the top cpuset which is allowed to contain boot
> time isolated CPUs.
>
> Commit ccac8e8de99c ("cgroup/cpuset: Fix remote root partition crea
On Thu, Oct 24, 2024 at 10:46:09AM +0530, Vishal Chourasia wrote:
> Fix incompatible function pointer type warnings in sched_ext BPF selftests by
> explicitly casting the function pointers when initializing struct_ops.
> This addresses multiple -Wincompatible-function-pointer-types warnings from
>
Hello,
On Wed, Oct 23, 2024 at 10:13:19PM +0530, Vishal Chourasia wrote:
...
> static int scx_ops_enable(struct sched_ext_ops *ops, struct bpf_link *link)
> {
> ...
> ret = validate_ops(ops);
> if (ret)
> goto err_disable;
> ...
> err_disable:
> mut
On Wed, Oct 23, 2024 at 02:15:00PM +0530, Vishal Chourasia wrote:
> Fix incompatible function pointer type warnings in sched_ext BPF selftests by
> explicitly casting the function pointers when initializing struct_ops.
> This addresses multiple -Wincompatible-function-pointer-types warnings from
>
On Fri, Oct 11, 2024 at 06:11:53AM +, Xiu Jianfeng wrote:
> From: Xiu Jianfeng
>
> When compiling the cgroup selftests with the following command:
>
> make -C tools/testing/selftests/cgroup/
>
> the compiler complains as below:
>
> test_cpu.c: In function ‘test_cpucg_nice’:
> test_cpu.c:28
On Tue, Oct 08, 2024 at 05:35:18PM +0200, Björn Töpel wrote:
> From: Björn Töpel
>
> The sched_ext selftests is missing proper cross-compilation support, a
> proper target entry, and out-of-tree build support.
>
> When building the kselftest suite, e.g.:
>
> make ARCH=riscv CROSS_COMPILE=risc
Hello, Michal.
On Thu, Sep 26, 2024 at 08:10:35PM +0200, Michal Koutný wrote:
...
> On Tue, Sep 10, 2024 at 11:01:07AM GMT, Tejun Heo wrote:
> > I think it's as useful as system-wide nice metric is.
>
> Exactly -- and I don't understand how that system-wide value (
Hello, Michal.
On Mon, Sep 02, 2024 at 05:45:39PM +0200, Michal Koutný wrote:
> - It makes (some) sense only on leave cgroups (where variously nice'd
> tasks are competing against each other). Not so much on inner node
> cgroups (where it's a mere sum but sibling cgroups could have different
>
On Fri, Mar 08, 2024 at 10:18:18AM +0800, Kassey Li wrote:
> The trace event "workqueue_activate_work" only print work struct.
> However, function is the region of interest in a full sequence of work.
> Current workqueue_activate_work trace event output:
>
> workqueue_activate_work: work struc
Hello,
On Fri, Feb 02, 2024 at 10:34:29AM -0600, Haitao Huang wrote:
> @tj, I had your Reviewed-by tags previously but dropped it due to some
> changes for refactoring suggested by other reviewers. Could you take a look
> at patches 1-2 for MiscController and confirm if I can have your Reviewed-by
Hello,
On Wed, Oct 04, 2023 at 10:45:08AM -0500, Haitao Huang wrote:
> So I will update to something like following. Let me know if that's correct
> understanding.
> @tj, I'd appreciate for your input on whether this is acceptable from
> cgroups side.
Yeah, that's fine by me and I can't tell what
date kernel/cgroup/misc.c to
> use the new name.
>
> Signed-off-by: Kristen Carlson Accardi
> Signed-off-by: Haitao Huang
Acked-by: Tejun Heo
Thanks.
--
tejun
On Tue, Sep 12, 2023 at 09:06:17PM -0700, Haitao Huang wrote:
> SGX EPC memory allocations are separate from normal RAM allocations, and
> are managed solely by the SGX subsystem. The existing cgroup memory
> controller cannot be used to limit or account for SGX EPC memory, which is
> a desirable f
On Fri, Sep 15, 2023 at 07:55:45AM -1000, Tejun Heo wrote:
> On Tue, Sep 12, 2023 at 09:06:18PM -0700, Haitao Huang wrote:
> > @@ -37,6 +37,11 @@ struct misc_res {
> > u64 max;
> > atomic64_t usage;
> > atomic64_t events;
> > +
> > + /* p
On Tue, Sep 12, 2023 at 09:06:18PM -0700, Haitao Huang wrote:
> @@ -37,6 +37,11 @@ struct misc_res {
> u64 max;
> atomic64_t usage;
> atomic64_t events;
> +
> + /* per resource callback ops */
> + int (*misc_cg_alloc)(struct misc_cg *cg);
> + void (*misc_cg_free)(struc
Hello,
Sorry about late reply.
On Wed, Apr 07, 2021 at 08:34:24PM +0200, Peter Zijlstra wrote:
> > Given the existence of prctl and clone APIs, I don't see the reason to
> > have a separate cgroup-bound interface too (as argued by Tejun).
>
> IMO as long as cgroups have that tasks file, you get
Hello, Christophe.
On Sun, Apr 18, 2021 at 11:25:52PM +0200, Christophe JAILLET wrote:
> Improve 'create_workqueue', 'create_freezable_workqueue' and
> 'create_singlethread_workqueue' so that they accept a format
> specifier and a variable number of arguments.
>
> This will put these macros more
On Tue, Apr 13, 2021 at 11:02:33AM +0200, Odin Ugedal wrote:
> Two small validation relaxations for cgroup v2, making it easier to
> manage the hierarchy without the current pain points. Both changes
> work for both mems and cpus (but I have no NUMA machine to test mems).
>
> Hopefully the patches
On Thu, Apr 08, 2021 at 04:03:46PM +0800, Lu Jialin wrote:
> Change hierachy to hierarchy and unrechable to unreachable,
> no functionality changed.
>
> Signed-off-by: Lu Jialin
Applied to cgroup/for-5.13.
Thanks.
--
tejun
Hello,
On Tue, Apr 06, 2021 at 08:57:15PM +0530, Pavan Kondeti wrote:
> Yeah. The workqueue attrs comes in handy to reduce the nice/prio of a
> background workqueue if we identify that it is cpu intensive. However, this
> needs case by case analysis, tweaking etc. If there is no other alternative,
Hello,
On Tue, Apr 06, 2021 at 05:32:04PM +0200, Peter Zijlstra wrote:
> > I find it difficult to like the proposed interface from the name (the term
> > "core" is really confusing given how the word tends to be used internally)
> > to the semantics (it isn't like anything else) and even the funct
Hello,
On Mon, Apr 05, 2021 at 02:46:09PM -0400, Joel Fernandes wrote:
> Yeah, its at http://lore.kernel.org/r/20200822030155.ga414...@google.com
> as mentioned above, let me know if you need any more details about
> usecase.
Except for the unspecified reason in usecase 4, I don't see why cgroup
Hello,
On Tue, Apr 06, 2021 at 06:34:21PM +0530, Pavankumar Kondeti wrote:
> In Android GKI, CONFIG_FAIR_GROUP_SCHED is enabled [1] to help prioritize
> important work. Given that CPU shares of root cgroup can't be changed,
> leaving the tasks inside root cgroup will give them higher share
> compa
Hello, Linus.
Two workqueue fixes. One is around debugobj and poses no risk. The other is
to prevent the stall watchdog from firing spuriously in certain conditions.
Not as trivial as debugobj change but is still fairly low risk.
Thanks.
The following changes since commit 2023a53bdf41b7646b1d384
cc'ing Michal and Christian who've been spending some time on cgroup
interface issues recently and Li Zefan for cpuset.
On Thu, Apr 01, 2021 at 03:10:12PM +0200, Peter Zijlstra wrote:
> The cgroup interface now uses a 'core_sched' file, which still takes 0,1. It
> is
> however changed such that y
ot;)
> Signed-off-by: Muchun Song
> Acked-by: Michal Hocko
Acked-by: Tejun Heo
Thanks.
--
tejun
Applied to cgroup/for-5.13. If there are further issues, let's address them
incrementally.
Thanks.
--
tejun
Applied to wq/for-5.12-fixes w/ minor description update.
Thanks.
--
tejun
Hello,
On Thu, Mar 25, 2021 at 02:57:44PM +0800, brookxu wrote:
> INTERFACE:
>
> The bfq.ioprio interface now is available for cgroup v1 and cgroup
> v2. Users can configure the ioprio for cgroup through this
> interface, as shown below:
>
> echo "1 2"> blkio.bfq.ioprio
>
> The above two values
ch.
>
> Signed-off-by: Jonathan Neuschäfer
Acked-by: Tejun Heo
Can you re-send with triv...@kernel.org cc'd?
Thanks.
--
tejun
On Fri, Mar 19, 2021 at 04:00:36PM +0800, Wang Qing wrote:
> When touch_softlockup_watchdog() is called, only wq_watchdog_touched_cpu
> updated, while the unbound worker_pool running on its core uses
> wq_watchdog_touched to determine whether locked up. This may be mischecked.
Can you please ela
On Mon, Mar 15, 2021 at 06:30:30PM -0700, Jacob Pan wrote:
> I don't know if this is required. I thought utilities such as cgclassify
> need to be supported.
> " cgclassify - move running task(s) to given cgroups "
> If no such use case, I am fine with dropping the migration support. Just
> enforce
Hello,
On Mon, Mar 15, 2021 at 04:40:12PM -0700, Jacob Pan wrote:
> 2. then we want to move/migrate Process1 to cg_B. so we need uncharge 10 of
> cg_A, charge 10 of cg_B
So, what I don't get is why this migration is necessary. This isn't
supported as a usage pattern and no one, at least in terms
Hello,
On Mon, Mar 15, 2021 at 03:11:55PM -0700, Jacob Pan wrote:
> > Migration itself doesn't have restrictions but all resources are
> > distributed on the same hierarchy, so the controllers are supposed to
> > follow the same conventions that can be implemented by all controllers.
> >
> Got it
Hello,
On Sun, Mar 14, 2021 at 01:58:33PM -0700, Shakeel Butt wrote:
> > If my understanding were correct, what Tejun suggested is to add a fast
> > read interface to rstat to be used in hot path. And its accuracy is
> > similar as that of traditional per-CPU counter. But if we can regularly
> >
Hello,
On Sat, Mar 13, 2021 at 08:57:01AM -0800, Jacob Pan wrote:
> Isn't PIDs controller doing the charge/uncharge? I was under the impression
> that each resource can be independently charged/uncharged, why it affects
> other resources? Sorry for the basic question.
Yeah, PID is an exception as
On Fri, Mar 12, 2021 at 02:59:04PM -0800, Jacob Pan wrote:
> Our primary goal is to limit the amount of IOASIDs that VMs can allocate.
> If a VM is migrated to a different cgroup, I think we need to
> charge/uncharge the destination/source cgroup in order enforce the limit. I
> am not an expert her
Hello,
On Thu, Mar 11, 2021 at 07:58:19PM +0100, Michal Koutný wrote:
> > Michal, as you've been reviewing the series, can you please take
> > another look and ack them if you don't find anything objectionable?
> Honestly, I'm still sitting on the fence whether this needs a new
> controller and wh
On Thu, Mar 11, 2021 at 02:17:52PM +0800, Chengming Zhou wrote:
> We have the netlink CGROUPSTATS_CMD_GET interface to get taskstats
> of the cgroup on v1, but haven't the equivalent interface on v2,
> making it difficult to calculate the per-cgroup cpu load in cadvisor
> or implement the cgroup pr
Hello,
On Thu, Mar 04, 2021 at 03:19:44PM -0800, Vipin Sharma wrote:
> This patch series is creating a new misc cgroup controller for limiting
> and tracking of resources which are not abstract like other cgroup
> controllers.
>
> This controller was initially proposed as encryption_id but after
> 8:0 Read 537448448
> > $ head -n 1 test/blkio.throttle.io_service_bytes_recursive
> > 8:0 Read 537448448
> >
> > Clearly, above data of "test" reflects "test2" not "test1"+"test2".
> >
> > Do the correct summary in blkg_rwstat_recursive_sum().
>
> LGTM, Tejun?
Gees, that's horrible. Thanks for fixing this.
Acked-by: Tejun Heo
--
tejun
Hello,
On Wed, Mar 03, 2021 at 10:12:32PM -0800, Vipin Sharma wrote:
> Right now there is no API for the caller to know total usage, unless they
> keep their own tally, I was thinking it will be useful to add one more API
>
> unsigned long misc_cg_res_total_usage(enum misc_res_type type)
>
> It
Hello,
On Wed, Mar 03, 2021 at 10:22:03PM -0800, Vipin Sharma wrote:
> > I am trying to see if IOASIDs cgroup can also fit in this misc controller
> > as yet another resource type.
> > https://lore.kernel.org/linux-iommu/20210303131726.7a8cb169@jacob-builder/T/#u
> > However, unlike sev IOASIDs ne
On Sat, Feb 27, 2021 at 02:01:23PM -0800, Jacob Pan wrote:
> IOASIDs are used to associate DMA requests with virtual address spaces.
> They are a system-wide limited resource made available to the userspace
> applications. Let it be VMs or user-space device drivers.
>
> This RFC patch introduces a
Hello,
On Tue, Mar 02, 2021 at 12:17:04AM -0800, Vipin Sharma wrote:
> +/**
> + * struct misc_res: Per cgroup per misc type resource
> + * @max: Maximum count of the resource.
> + * @usage: Current usage of the resource.
> + */
> +struct misc_res {
> + unsigned int max;
> + atomic_t usage;
On Thu, Feb 18, 2021 at 11:16:49AM +0800, qiang.zh...@windriver.com wrote:
> From: Zqiang
>
> The debug_work_activate() is called on the premise that
> the work can be inserted, because if wq be in WQ_DRAINING
> status, insert work may be failed.
>
> Fixes: e41e704bc4f4 ("workqueue: improve dest
mstat in x86 servers
...
> Signed-off-by: Saravanan D
> Acked-by: Tejun Heo
> Acked-by: Johannes Weiner
> Acked-by: Dave Hansen
Andrew, do you mind picking this one up? It has enough acks and can go
through either mm or x86 tree.
Thank you.
--
tejun
Hello,
Tracepoint and comment updates only.
Thanks.
The following changes since commit 1e2a199f6ccdc15cf111d68d212e2fd4ce65682e:
Merge tag 'spi-fix-v5.11-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi (2021-01-18 11:23:05
-0800)
are available in the Git repository at:
Hello, Linus.
Nothing interesting. Just two minor patches.
Thanks.
The following changes since commit b5e56576e16236de3c035ca86cd3ef16591722fb:
MAINTAINERS: Update my email address (2021-01-15 15:33:06 -0500)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kerne
Hello, Linus.
Two cgroup fixes: 1. Fix the NULL deref when trying to poll PSI in the root
cgroup and 2. fix confusing controller parsing corner case when mounting
cgroup v1 hierarchies. And doc / maintainer file updates.
Thanks.
The following changes since commit f4e087c666f54559cb4e530af1fbfc99
Hello,
On Tue, Feb 09, 2021 at 02:17:19PM +0100, Odin Ugedal wrote:
> A am not that familiar how cross subsystem patches like these are handled, but
> I am still adding the Tejun Heo (cgroup maintainer) as a CC. Should maybe cc
> to
> cgroup@ as well?
Yeah, that'd be great
Hello,
On Mon, Feb 08, 2021 at 03:54:14PM -0500, Johannes Weiner wrote:
> We probably do need a better solution for the lruvecs as well, but in
> this case it just started holding up fixing the memory.stat issue for
> no reason and so I tabled it for another patch series.
rstat doesn't currently
Hello,
On Mon, Feb 08, 2021 at 03:29:21PM -0500, Johannes Weiner wrote:
> > > @@ -789,6 +793,7 @@ static void blkcg_rstat_flush(struct
> > > cgroup_subsys_state *css, int cpu)
> > > u64_stats_update_end(&blkg->iostat.sync);
> > >
> > > /* propagate global delta to parent */
On Fri, Feb 05, 2021 at 01:27:58PM -0500, Johannes Weiner wrote:
> This is version 2 of the memcg rstat patches. Updates since v1:
>
> - added cgroup selftest output (see test section below) (thanks Roman)
> - updated cgroup selftest to match new kernel implementation
> - added Fixes: tag to 'mm:
ueueing for a flush touches only per-cpu data, and only the first
> stat change since a flush requires a (per-cpu) lock.
>
> Signed-off-by: Johannes Weiner
Generally looks good to me.
Acked-by: Tejun Heo
A couple nits below.
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
&g
on unmount, the css moves back to the default hierarchy. Annotate
> rebind_subsystems() to move the root css linkage along between roots.
>
> Signed-off-by: Johannes Weiner
> Reviewed-by: Roman Gushchin
Acked-by: Tejun Heo
Thanks.
--
tejun
x86 servers
...
> Signed-off-by: Saravanan D
Acked-by: Tejun Heo
Thanks.
--
tejun
On Thu, Jan 28, 2021 at 04:25:32PM +0800, Abaci Team wrote:
> Fix the following coccicheck warnings:
>
> ./fs/kernfs/file.c:647:1-3: WARNING: possible condition with no effect
> (if == else).
>
> Reported-by: Abaci Robot
> Suggested-by: Jiapeng Zhong
> Signed-off-by: Abaci Team
> ---
> fs/ker
+0x164/0x468
> [ 4757.010705] kthread+0x108/0x138
>
> Suggested-by: Tejun Heo
> Signed-off-by: Baolin Wang
Acked-by: Tejun Heo
Thanks.
--
tejun
Hello,
On Wed, Jan 27, 2021 at 01:32:03PM -0800, Dave Hansen wrote:
> >> arch/x86/mm/pat/set_memory.c | 117 ++
> >> include/linux/vm_event_item.h | 8 +++
> >> mm/vmstat.c | 8 +++
> >> 3 files changed, 133 insertions(+)
> >
> > So, now the
Hello,
On Wed, Jan 27, 2021 at 09:51:24AM -0800, Saravanan D wrote:
> Numerous hugepage splits in the linear mapping would give
> admins the signal to narrow down the sluggishness caused by TLB
> miss/reload.
>
> To help with debugging, we introduce monotonic lifetime hugepage
> split event coun
On Sat, Jan 23, 2021 at 04:04:00PM +0800, Stephen Zhang wrote:
> It is better to replace the function name with %s, in case the function
> name changes.
>
> Signed-off-by: Stephen Zhang
Applied to wq/for-5.12.
Thanks.
--
tejun
Hello, Baolin.
On Tue, Jan 26, 2021 at 09:33:25PM +0800, Baolin Wang wrote:
> On !PREEMPT kernel, we can get below softlockup when doing stress
> testing with creating and destroying block cgroup repeatly. The
> reason is it may take a long time to acquire the queue's lock in
> the loop of blkcg_d
Hello,
On Tue, Jan 26, 2021 at 05:11:59PM -0800, Vipin Sharma wrote:
> Sounds good, we can have a single top level stat file
>
> misc.stat
> Shows how many are supported on the host:
> $ cat misc.stat
> sev 500
> sev_es 10
>
> If total value of some resource is 0 then it will be consider
On Tue, Jan 26, 2021 at 05:01:04PM -0500, Tejun Heo wrote:
> * misc.max and misc.current: nested keyed files listing max and current
> usage for the cgroup.
Keyed files, not nested keyed files.
Thanks.
--
tejun
Hello,
On Tue, Jan 26, 2021 at 12:49:14PM -0800, David Rientjes wrote:
> > SEV-SNP, another incremental enhancement (on SEV-ES), further strengthens
> > the
> > argument for SEV and SEV-* coexistenence. SEV-SNP and SEV-ES will share the
> > same ASID range, so the question is really, "do we expe
Hello, Dave.
On Mon, Jan 25, 2021 at 04:47:42PM -0800, Dave Hansen wrote:
> The patch here does not actually separate out pre-boot from post-boot,
> so it's pretty hard to tell if the splits came from something like
> tracing which is totally unnecessary or they were the result of
> something at b
Hello,
On Mon, Jan 25, 2021 at 05:04:00PM -0800, Dave Hansen wrote:
> Which part? Large production environments don't trust data from
> debugfs? Or don't trust it if it might have been reset?
When the last reset was. Not saying it's impossible or anything but in
general it's a lot better to hav
see __group_cmp().
>
> Due to 'const' we had to touch cgroup_id().
>
> Cc: Tejun Heo
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Tejun Heo
Thanks.
--
tejun
Hello,
On Mon, Jan 25, 2021 at 12:15:51PM -0800, Dave Hansen wrote:
> > DirectMap4k: 3505112 kB
> > DirectMap2M:19464192 kB
> > DirectMap1G:12582912 kB
> > DirectMap2MSplits: 1705
> > DirectMap1GSplits:20
>
> This seems much more like something we'd want in /proc/vmstat or as a
>
Hello,
On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote:
> The hardware will allow any SEV capable ASID to be run as SEV-ES, however,
> the SEV firmware will not allow the activation of an SEV-ES VM to be
> assigned to an ASID greater than or equal to the SEV minimum ASID value. The
>
Hello,
On Wed, Jan 20, 2021 at 03:18:29PM -0800, Vipin Sharma wrote:
> RDMA cgroup expose hardware details to users. In rdma.{max, current}
> interface files we can see actual hardware names. Only difference
No, what's shown is the device name followed by resources which are commonly
defined for
Hello,
On Tue, Jan 19, 2021 at 11:13:51PM -0800, Vipin Sharma wrote:
> > Can you please elaborate? I skimmed through the amd manual and it seemed to
> > say that SEV-ES ASIDs are superset of SEV but !SEV-ES ASIDs. What's the use
> > case for mixing those two?
>
> For example, customers can be giv
On Tue, Jan 19, 2021 at 11:56:18AM -0500, Johannes Weiner wrote:
> On Sat, Jan 16, 2021 at 06:36:34PM +0100, Odin Ugedal wrote:
> > Update PSI file description in cgroup-v2 docs to reflect the current
> > implementation.
> >
> > Signed-off-by: Odin Ugedal
> > ---
> > Documentation/admin-guide/cg
On Sat, Jan 16, 2021 at 06:36:32PM +0100, Odin Ugedal wrote:
> This patchset fixes PSI monitors on the root cgroup, as they currently
> only works on the non-root cgroups. Reading works for all, since that
> was fixed when adding support for the root PSI files. It also contains
> a doc update to re
wq is changed.
Yeah, this approach makes sense to me. It doesn't look like all problems are
resolved but for the rescuer behavior part, please feel free to add
Acked-by: Tejun Heo
Thanks.
--
tejun
On Mon, Jan 04, 2021 at 08:43:06PM +0800, qiang.zh...@windriver.com wrote:
> From: Zqiang
>
> This patch tracing workqueue name instead of it's address, the
> new format is as follows.
>
> workqueue_queue_work: work struct=84e3df56 function=
> drm_fb_helper_dirty_work workqueue=events re
Hello,
On Fri, Jan 15, 2021 at 08:32:19PM -0800, Vipin Sharma wrote:
> SEV-ES has stronger memory encryption gurantees compared to SEV, apart
> from encrypting the application memory it also encrypts register state
> among other things. In a single host ASIDs can be distributed between
> these two
On Mon, Jan 18, 2021 at 12:04:55AM -0800, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> 'wq_sysfs_register()' in annotation for 'WQ_SYSFS' is unavailable,
> change it to 'workqueue_sysfs_register()'.
>
> Signed-off-by: Menglong Dong
Applied to wq/for-5.12.
Thanks.
--
tejun
On Fri, Jan 15, 2021 at 02:18:40PM -0800, Vipin Sharma wrote:
> > * Why is .sev a separate namespace? Isn't the controller supposed to cover
> > encryption ids across different implementations? It's not like multiple
> > types of IDs can be in use on the same machine, right?
> >
>
> On AMD pl
On Thu, Jan 07, 2021 at 05:28:46PM -0800, Vipin Sharma wrote:
> Documentation for both cgroup versions, v1 and v2, of Encryption IDs
> controller. This new controller is used to track and limit usage of
> hardware memory encryption capabilities on the CPUs.
>
> Signed-off-by: Vipin Sharma
> Revie
Hello,
On Thu, Jan 07, 2021 at 05:28:45PM -0800, Vipin Sharma wrote:
> 1. encrpytion_ids.sev.max
> Sets the maximum usage of SEV IDs in the cgroup.
> 2. encryption_ids.sev.current
> Current usage of SEV IDs in the cgroup and its children.
> 3. encryption_ids.sev.stat
> Shown only
On Wed, Jan 13, 2021 at 12:37:41PM +0800, Aubrey Li wrote:
> Change hierachy to hierarchy and congifured to configured, no functionality
> changed.
>
> Signed-off-by: Aubrey Li
Applied to cgroup/for-5.12.
Thanks.
--
tejun
On Wed, Jan 13, 2021 at 04:59:42PM +0800, Zefan Li wrote:
> Signed-off-by: Zefan Li
Applied 1-2 to cgroup/for-5.11-fixes.
Thanks.
--
tejun
On Thu, Jan 14, 2021 at 01:44:27PM +0100, Michal Koutný wrote:
> Hello.
>
> On Sun, Jan 03, 2021 at 02:50:01AM +, Hao Lee
> wrote:
> > The string buf will be stripped in cgroup_procs_write_start() before it
> > is converted to int, so remove this unnecessary call to strstrip().
> Good catch,
On Fri, Jan 15, 2021 at 05:37:17PM +0800, Chen Zhou wrote:
> When mounting a cgroup hierarchy with disabled controller in cgroup v1,
> all available controllers will be attached.
> For example, boot with cgroup_no_v1=cpu or cgroup_disable=cpu, and then
> mount with "mount -t cgroup -ocpu cpu /sys/f
Hello,
On Fri, Jan 15, 2021 at 09:55:43AM +0800, chenzhou wrote:
> Yeah, this will select all enabled controllers, but which doesn't the
> behavior we want.
> I think the case should return error with information "Disabled controller
> xx" rather than
> attaching all the other enabled controller
Happy new year!
On Wed, Dec 16, 2020 at 12:02:37PM -0800, Vipin Sharma wrote:
> I like the idea of having a separate controller to keep the code simple and
> easier for maintenance.
Yeah, the more I think about it, keeping it separate seems like the right
thing to do. What bothers me primarily is
1 - 100 of 8145 matches
Mail list logo
