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
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
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
l/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
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
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
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
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
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
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
>
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
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
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
patch.
>
> 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
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
>
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
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
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
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
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
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
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
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
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
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:
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
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
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(>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:
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
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
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
> ---
>
4/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
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
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
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
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
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
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
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
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
> > ---
> >
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
>
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
>
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
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
> -
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,
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
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
tate tracing.
>
> Signed-off-by: Baolin Wang
Acked-by: Tejun Heo
Thanks.
--
tejun
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
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
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
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
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
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
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
1 - 100 of 22291 matches
Mail list logo
