Re: [PATCH 0/9] sched: Core scheduling interfaces

2021-04-19 Thread Tejun Heo
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

Re: [PATCH 0/2] workqueue: Have 'alloc_workqueue()' like macros accept a format specifier

2021-04-19 Thread Tejun Heo
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

Re: [PATCH 0/2] Relax cpuset validation for cgroup v2

2021-04-13 Thread Tejun Heo
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

Re: [PATCH -next] cgroup/cpuset: fix typos in comments

2021-04-12 Thread Tejun Heo
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

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

2021-04-06 Thread Tejun Heo
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

Re: [PATCH 0/9] sched: Core scheduling interfaces

2021-04-06 Thread Tejun Heo
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

Re: [PATCH 0/9] sched: Core scheduling interfaces

2021-04-06 Thread Tejun Heo
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

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

2021-04-06 Thread Tejun Heo
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 >

[GIT PULL] wq fixes for v5.12-rc6

2021-04-05 Thread Tejun Heo
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

Re: [PATCH 0/9] sched: Core scheduling interfaces

2021-04-04 Thread Tejun Heo
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

Re: [PATCH v3] writeback: fix obtain a reference to a freeing memcg css

2021-04-04 Thread Tejun Heo
ot;) > Signed-off-by: Muchun Song > Acked-by: Michal Hocko Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH v4 0/3] cgroup: New misc cgroup controller

2021-04-04 Thread Tejun Heo
Applied to cgroup/for-5.13. If there are further issues, let's address them incrementally. Thanks. -- tejun

Re: [PATCH V3,RESEND] workqueue/watchdog: Make unbound workqueues aware of touch_softlockup_watchdog()

2021-04-04 Thread Tejun Heo
Applied to wq/for-5.12-fixes w/ minor description update. Thanks. -- tejun

Re: [PATCH v3 00/14] bfq: introduce bfq.ioprio for cgroup

2021-04-04 Thread Tejun Heo
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

Re: [PATCH] workqueue: Switch to new kerneldoc syntax for named variable macro argument

2021-03-20 Thread Tejun Heo
patch. > > Signed-off-by: Jonathan Neuschäfer Acked-by: Tejun Heo Can you re-send with triv...@kernel.org cc'd? Thanks. -- tejun

Re: [PATCH V2] workqueue: watchdog: update wq_watchdog_touched for unbound lockup checking

2021-03-20 Thread Tejun Heo
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

Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

2021-03-15 Thread Tejun Heo
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 >

Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

2021-03-15 Thread Tejun Heo
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

Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

2021-03-15 Thread Tejun Heo
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

Re: [PATCH] vmscan: retry without cache trim mode if nothing scanned

2021-03-14 Thread Tejun Heo
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 >

Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

2021-03-13 Thread Tejun Heo
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

Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

2021-03-13 Thread Tejun Heo
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

Re: [Patch v3 0/2] cgroup: New misc cgroup controller

2021-03-11 Thread Tejun Heo
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

Re: [PATCH] cgroup-v2: Add taskstats counters in cgroup.stat

2021-03-11 Thread Tejun Heo
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

Re: [Patch v3 0/2] cgroup: New misc cgroup controller

2021-03-07 Thread Tejun Heo
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

Re: [PATCH] blk-cgroup: Fix the recursive blkg rwstat

2021-03-07 Thread Tejun Heo
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

Re: [RFC v2 1/2] cgroup: sev: Add misc cgroup controller

2021-03-04 Thread Tejun Heo
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

Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

2021-03-04 Thread Tejun Heo
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

Re: [RFC PATCH 15/18] cgroup: Introduce ioasids controller

2021-03-03 Thread Tejun Heo
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

Re: [RFC v2 1/2] cgroup: sev: Add misc cgroup controller

2021-03-03 Thread Tejun Heo
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

Re: [PATCH v2] workqueue: Move the position of debug_work_activate() in __queue_work()

2021-03-03 Thread Tejun Heo
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

Re: [PATCH V6] x86/mm: Tracking linear mapping split events

2021-03-01 Thread Tejun Heo
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

[GIT PULL] workqueue changes for v5.12-rc1

2021-02-21 Thread Tejun Heo
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:

[GIT PULL] cgroup changes for v5.12-rc1

2021-02-21 Thread Tejun Heo
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 PULL] cgroup fixes for v5.11-rc7

2021-02-13 Thread Tejun Heo
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

Re: [PATCH v3 0/4] sched/fair: Burstable CFS bandwidth controller

2021-02-09 Thread Tejun Heo
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. Giv

Re: [PATCH 7/8] mm: memcontrol: consolidate lruvec stat flushing

2021-02-08 Thread Tejun Heo
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

Re: [PATCH 5/8] cgroup: rstat: punt root-level optimization to individual controllers

2021-02-08 Thread Tejun Heo
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(>iostat.sync); > > > > > > /* propagate global delta to parent */ > > >

Re: [PATCH 0/8] mm: memcontrol: switch to rstat v2

2021-02-05 Thread Tejun Heo
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:

Re: [PATCH 5/8] cgroup: rstat: punt root-level optimization to individual controllers

2021-02-05 Thread Tejun Heo
lush 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 > index 02ce20

Re: [PATCH 4/8] cgroup: rstat: support cgroup1

2021-02-05 Thread Tejun Heo
mount, 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

Re: [PATCH V6] x86/mm: Tracking linear mapping split events

2021-01-28 Thread Tejun Heo
x86 servers ... > Signed-off-by: Saravanan D Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH] kernfs: Remove redundant code

2021-01-28 Thread Tejun Heo
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 > --- >

Re: [PATCH v2] blk-cgroup: Use cond_resched() when destroy blkgs

2021-01-27 Thread Tejun Heo
4/0x468 > [ 4757.010705]  kthread+0x108/0x138 > > Suggested-by: Tejun Heo > Signed-off-by: Baolin Wang Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH V2] x86/mm: Tracking linear mapping split events

2021-01-27 Thread Tejun Heo
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

Re: [PATCH V2] x86/mm: Tracking linear mapping split events

2021-01-27 Thread Tejun Heo
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

Re: [PATCH] workqueue: Use %s instead of function name

2021-01-27 Thread Tejun Heo
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

Re: [PATCH] blk-cgroup: Use cond_resched() when destroy blkgs

2021-01-27 Thread Tejun Heo
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

Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-27 Thread Tejun Heo
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

Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-26 Thread Tejun Heo
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

Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-26 Thread Tejun Heo
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

Re: [PATCH] x86/mm: Tracking linear mapping split events since boot

2021-01-26 Thread Tejun Heo
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

Re: [PATCH] x86/mm: Tracking linear mapping split events since boot

2021-01-26 Thread Tejun Heo
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

Re: [PATCH v2 4/7] rbtree, perf: Use new rbtree helpers

2021-01-25 Thread Tejun Heo
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

Re: [PATCH] x86/mm: Tracking linear mapping split events since boot

2021-01-25 Thread Tejun Heo
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

Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-21 Thread Tejun Heo
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 >

Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-20 Thread Tejun Heo
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

Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-20 Thread Tejun Heo
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

Re: [PATCH v2 2/2] cgroup: update PSI file description in docs

2021-01-19 Thread Tejun Heo
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 > > --- > >

Re: [PATCH v2 0/2] cgroup: fix psi monitor for root cgroup

2021-01-19 Thread Tejun Heo
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: [PATCH] workqueue: keep unbound rescuer's cpumask to be default cpumask

2021-01-19 Thread Tejun Heo
se 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

Re: [PATCH] workqueue: tracing the name of the workqueue instead of it's address

2021-01-19 Thread Tejun Heo
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: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-19 Thread Tejun Heo
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

Re: [PATCH] workqueue: fix annotation for WQ_SYSFS

2021-01-19 Thread Tejun Heo
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

Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-15 Thread Tejun Heo
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

Re: [Patch v4 2/2] cgroup: svm: Encryption IDs cgroup documentation.

2021-01-15 Thread Tejun Heo
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 >

Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

2021-01-15 Thread Tejun Heo
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

Re: [PATCH] cpuset: fix typos in comments

2021-01-15 Thread Tejun Heo
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

Re: [PATCH v2 2/2] MAINTAINERS: Update my email address

2021-01-15 Thread Tejun Heo
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

Re: [PATCH] cgroup: Remove unnecessary call to strstrip()

2021-01-15 Thread Tejun Heo
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

Re: [PATCH v3] cgroup-v1: add disabled controller check in cgroup1_parse_param()

2021-01-15 Thread Tejun Heo
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

Re: [PATCH v2] cgroup-v1: add disabled controller check in cgroup1_parse_param()

2021-01-14 Thread Tejun Heo
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

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2021-01-05 Thread Tejun Heo
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

[GIT PULL] workqueue changes for v5.11-rc1

2020-12-28 Thread Tejun Heo
Hello, again. The same as the cgroup tree - one commit which was scheduled for the 5.11 merge window. All the commit does is avoding spurious worker wakeups from workqueue allocation / config change path to help cpuisol use cases. Thank you. The following changes since commit

[GIT PULL] cgroup changes for v5.11-rc1

2020-12-28 Thread Tejun Heo
Hello, Linus. These three patches were scheduled for the merge window but I forgot to send them out. Sorry about that. None of them are significant and they fit well in a fix pull request too - two are cosmetic and one fixes a memory leak in the mount option parsing path. Thanks and happy

Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

2020-12-19 Thread Tejun Heo
Hello, On Sat, Dec 19, 2020 at 03:08:13PM +0800, Ian Kent wrote: > And looking further I see there's a race that kernfs can't do anything > about between kernfs_refresh_inode() and fs/inode.c:update_times(). Do kernfs files end up calling into that path tho? Doesn't look like it to me but if so

Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

2020-12-18 Thread Tejun Heo
Hello, On Fri, Dec 18, 2020 at 03:36:21PM +0800, Ian Kent wrote: > Sounds like your saying it would be ok to add a lock to the > attrs structure, am I correct? Yeah, adding a lock to attrs is a lot less of a problem and it looks like it's gonna have to be either that or hashed locks, which might

Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

2020-12-17 Thread Tejun Heo
Hello, On Thu, Dec 17, 2020 at 07:48:49PM +0800, Ian Kent wrote: > > What could be done is to make the kernfs node attr_mutex > > a pointer and dynamically allocate it but even that is too > > costly a size addition to the kernfs node structure as > > Tejun has said. > > I guess the question to

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2020-12-16 Thread Tejun Heo
Hello, On Thu, Dec 10, 2020 at 03:44:35PM -0800, David Rientjes wrote: > Concern with a single misc controller would be that any subsystem that > wants to use it has to exactly fit this support: current, max, stat, > nothing more. The moment a controller needs some additional support, and >

Re: [PATCH 2/2] blk-iocost: Use alloc_percpu_gfp() to simplify the code

2020-12-16 Thread Tejun Heo
Hello, On Fri, Dec 11, 2020 at 03:13:29PM +0800, Baolin Wang wrote: > Thanks for teaching me this, at least I did not get this from the local_ops > Documentation before. Just out of curiosity, these local[64]_t variables are > also allocated from budy allocator ultimately, why they can not be >

Re: [PATCH v2] cgroup: Fix memory leak when parsing multiple source parameters

2020-12-16 Thread Tejun Heo
On Thu, Dec 10, 2020 at 09:29:43AM +0800, Qinglang Miao wrote: > A memory leak is found in cgroup1_parse_param() when multiple source > parameters overwrite fc->source in the fs_context struct without free. > > unreferenced object 0x888100d930e0 (size 16): > comm "mount", pid 520, jiffies

Re: [PATCH 07/10] workqueue: Manually break affinity on hotplug for unbound pool

2020-12-16 Thread Tejun Heo
On Mon, Dec 14, 2020 at 11:54:54PM +0800, Lai Jiangshan wrote: > * An unbound pool may end up with a cpumask which doesn't have any online > - * CPUs. When a worker of such pool get scheduled, the scheduler resets > - * its cpus_allowed. If @cpu is in @pool's cpumask which didn't have any > -

Re: [PATCH 04/10] workqueue: don't set the worker's cpumask when kthread_bind_mask()

2020-12-16 Thread Tejun Heo
On Mon, Dec 14, 2020 at 11:54:51PM +0800, Lai Jiangshan wrote: > @@ -1945,7 +1945,15 @@ static struct worker *create_worker(struct worker_pool > *pool) > goto fail; > > set_user_nice(worker->task, pool->attrs->nice); > - kthread_bind_mask(worker->task,

Re: [PATCH 02/10] workqueue: use cpu_possible_mask instead of cpu_active_mask to break affinity

2020-12-16 Thread Tejun Heo
Hello, On Mon, Dec 14, 2020 at 11:54:49PM +0800, Lai Jiangshan wrote: > @@ -4909,8 +4909,9 @@ static void unbind_workers(int cpu) > > raw_spin_unlock_irq(>lock); > > + /* don't rely on the scheduler to force break affinity for us. > */ I'm not sure this comment is

Re: [PATCH 00/10] workqueue: break affinity initiatively

2020-12-16 Thread Tejun Heo
he patchset is a complement for 06249738a41a ("workqueue: > Manually break affinity on hotplug") which is only in tip/master by now. > > [1]: > https://lore.kernel.org/r/ff62e3ee994efb3620177bf7b19fab16f4866845.ca...@redhat.com Generally looks good to me. Please feel free to add Acked-by: Tejun Heo and route the series through tip. Thanks. -- tejun

Re: [PATCH 1/2] blk-iocost: Add iocg idle state tracepoint

2020-12-10 Thread Tejun Heo
tate tracing. > > Signed-off-by: Baolin Wang Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH 2/2] blk-iocost: Use alloc_percpu_gfp() to simplify the code

2020-12-10 Thread Tejun Heo
Hello, On Thu, Dec 10, 2020 at 06:56:45PM +0800, Baolin Wang wrote: > Use alloc_percpu_gfp() with __GFP_ZERO flag, which can remove > some explicit initialization code. __GFP_ZERO is implicit for percpu allocations and local[64]_t's initial states aren't guaranteed to be all zeros on different

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2020-12-09 Thread Tejun Heo
Hello, Rough take after skimming: * I don't have an overall objection. In terms of behavior, the only thing which stood out was input rejection depending on the current usage. The preferred way of handling that is rejecting future allocations rather than failing configuration as that makes

Re: [PATCH -tip 26/32] sched: Add a second-level tag for nested CGroup usecase

2020-12-04 Thread Tejun Heo
Hello, On Thu, Dec 03, 2020 at 04:51:42PM -0800, Josh Don wrote: > > So me the color thing reads like an end-run around the cgroup hierarchy. > > Restructuring the cgroup resource hierarchy to incorporate the trust > domains is not necessarily trivial (as is the case for us). I agree > though

Re: [RFC PATCH] workqueue: cut wq_rr_cpu_last

2020-12-03 Thread Tejun Heo
Hello, On Thu, Dec 03, 2020 at 06:28:41PM +0800, Hillf Danton wrote: > + new_cpu = cpumask_any_and_distribute(wq_unbound_cpumask, > cpu_online_mask); > + if (new_cpu < nr_cpu_ids) > + return new_cpu; > + else > + return cpu; > } > > static void

Re: [PATCH] mm: mmap_lock: fix use-after-free race and css ref leak in tracepoints

2020-12-02 Thread Tejun Heo
Hello, On Wed, Dec 02, 2020 at 03:23:57PM -0800, Shakeel Butt wrote: > > There've been some changes to cgroup ids recently and now cgroup id, ino and > > its file_handle are all compatible. On 64bit ino machines, they're all the > > same and won't be reused. On 32bit ino machines, the lower 32bit

Re: [RFC PATCH] blk-iocost: Optimize the ioc_refreash_vrate() function

2020-12-02 Thread Tejun Heo
On Sun, Nov 29, 2020 at 10:37:18AM +0800, Baolin Wang wrote: > The ioc_refreash_vrate() will only be called in ioc_timer_fn() after > starting a new period or stopping the period. > > So when starting a new period, the variable 'pleft' in ioc_refreash_vrate() > is always the period's time, which

Re: [PATCH v2 5/5] blk-iocost: Factor out the base vrate change into a separate function

2020-12-02 Thread Tejun Heo
On Thu, Nov 26, 2020 at 04:16:15PM +0800, Baolin Wang wrote: > Factor out the base vrate change code into a separate function > to fimplify the ioc_timer_fn(). > > No functional change. > > Signed-off-by: Baolin Wang Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH v2 4/5] blk-iocost: Factor out the active iocgs' state check into a separate function

2020-12-02 Thread Tejun Heo
On Thu, Nov 26, 2020 at 04:16:14PM +0800, Baolin Wang wrote: > Factor out the iocgs' state check into a separate function to > simplify the ioc_timer_fn(). > > No functional change. > > Signed-off-by: Baolin Wang Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH v2 3/5] blk-iocost: Move the usage ratio calculation to the correct place

2020-12-02 Thread Tejun Heo
avoid unnecessary calculation for some vtime shortage iocgs. > > Signed-off-by: Baolin Wang Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH] blk-throttle: don't check whether or not lower limit is valid if CONFIG_BLK_DEV_THROTTLING_LOW is off

2020-12-02 Thread Tejun Heo
of > time will be wasted to iterate descendants. > > Thus do nothing in blk_throtl_update_limit_valid() in such situation. > > Signed-off-by: Yu Kuai Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH] mm: mmap_lock: fix use-after-free race and css ref leak in tracepoints

2020-12-02 Thread Tejun Heo
Hello, On Tue, Dec 01, 2020 at 12:53:46PM -0800, Shakeel Butt wrote: > The writeback tracepoint in include/trace/events/writeback.h is > already using the cgroup IDs. Actually it used to use cgroup_path but > converted to cgroup_ino. > > Tejun, how do you use these tracepoints? There've been

Re: [PATCH -tip 26/32] sched: Add a second-level tag for nested CGroup usecase

2020-12-02 Thread Tejun Heo
Hello, On Wed, Dec 02, 2020 at 09:02:11AM +0100, Peter Zijlstra wrote: > > the user might only want subsets of {B, C, D, E} to share. For > > instance, the user might only want {B,C} and {D, E} to share. One way > > to solve this would be to allow the user to write the group cookie > >

Re: [PATCH 2/2] kernfs: remove mutex in kernfs_dop_revalidate

2020-12-02 Thread Tejun Heo
Hello, On Wed, Dec 02, 2020 at 10:58:37PM +0800, Fox Chen wrote: > There is a big mutex in kernfs_dop_revalidate which slows down the > concurrent performance of kernfs. > > Since kernfs_dop_revalidate only does some checks, the lock is > largely unnecessary. Also, according to kernel filesystem

Re: [PATCH 1/2] kernfs: replace the mutex in kernfs_iop_permission with a rwlock

2020-12-02 Thread Tejun Heo
On Wed, Dec 02, 2020 at 10:58:36PM +0800, Fox Chen wrote: > diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h > index 89f6a4214a70..545cdb39b34b 100644 > --- a/include/linux/kernfs.h > +++ b/include/linux/kernfs.h > @@ -156,6 +156,7 @@ struct kernfs_node { > unsigned short

  1   2   3   4   5   6   7   8   9   10   >