collpase in the subject line should be collapse
-- Tim
> -Original Message-
> From: Baolin Wang
> Subject: [PATCH 2/2] selftests: mm: add shmem collpase as a default test item
>
> Currently, we only test anonymous memory collapse by default. We should also
> add s
> -Original Message-
> From: Thomas Gleixner
> On Tue, Apr 08 2025 at 17:34, Tim Bird wrote:
> >> -Original Message-
> > For what it's worth, I've always been a bit skeptical of the use of the
> > python git module
> > in spd
f the python 'git' module, and submitting it for review.
Thanks,
-- Tim
le to only
hypercalls expected from the kernel.
Signed-off-by: Tim Merrifield
---
arch/x86/kernel/cpu/vmware.c | 51
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 00189cd
Add a new process-level prctl option to enable/disable user-level
hypercalls when running in a confidential VM. Add support for
checking this flag on VMCALL #VE for TDX and transfer control to
a hypervisor vendor-specific handler.
Signed-off-by: Tim Merrifield
---
arch/x86/coco/tdx/tdx.c
h 2: We now zero tdx_module_args to prevent data leakage to the VMM,
pointed out by Kirill.
Tim Merrifield (2):
Add prctl to allow userlevel TDX hypercalls
x86/vmware: VMware support for TDX userspace hypercalls
arch/x86/coco/tdx/tdx.c | 23 ++
arch/x86/include/asm/mm
Thanks for the review, Kirill.
On Mon, Jul 08, 2024 at 03:19:54PM +0300, Kirill A . Shutemov wrote:
> Hm. Per-thread flag is odd. I think it should be per-process.
This is the only point I might need some clarification on. I agree
there doesn't seem to be much value in allowing per-thread contr
On Thu, Jul 04, 2024 at 03:05:05PM +0200, Peter Zijlstra wrote:
> And how are we to ascertain the software using these hooks is deemed
> secure? What security risks are there for the kernel if a malicious
> userspace process asks for these rights?
>
> The kernel must assume malice on the part of u
Thanks for the response, Dave.
On Wed, Jul 03, 2024 at 05:18:22PM -0700, Dave Hansen wrote:
>
> Could we please be frank and transparent about what you actually want
> here and how you expect this mechanism to be used?
>
Sorry for being unclear. open-vm-tools is currently broken on TDX and
the
le to only
hypercalls expected from the kernel.
Signed-off-by: Tim Merrifield
---
arch/x86/kernel/cpu/vmware.c | 51
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 00189cd
Add a new prctl option to enable/disable user-level hypercalls when
running in a confidential VM. Add support for checking this flag on
VMCALL #VE for TDX and transfer control to a hypervisor
vendor-specific handler.
Signed-off-by: Tim Merrifield
---
arch/x86/coco/tdx/tdx.c| 18
sev_es_hcall_prepare/sev_es_hcall_finish). The flag has no effect on
non-TDX VMs. Other confidential computing technologies could use this flag
to provide limited access to user-level hypercalls.
Tim Merrifield (2):
x86/tdx: Add prctl to allow userlevel TDX hypercalls
x86/vmware: VMware support for TDX userspace
Add a count of files missing an SPDX header to the stats
output. This is useful detailed information for working
on SPDX header additions.
Signed-off-by: Tim Bird
---
scripts/spdxcheck.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/spdxcheck.py b/scripts/spdxcheck.py
index
x27;t need to be allocated.
>
> Link:
> https://lore.kernel.org/linux-trace-kernel/20240212174011.06821...@gandalf.local.home/
>
> Signed-off-by: Steven Rostedt (Google)
Patch looks good to me.
Reviewd-by: Tim Chen
> ---
> Changes since v1:
> https://lore.kernel.org
On Mon, 2024-02-12 at 19:13 -0500, Steven Rostedt wrote:
> On Mon, 12 Feb 2024 15:39:03 -0800
> Tim Chen wrote:
>
> > > diff --git a/kernel/trace/trace_sched_switch.c
> > > b/kernel/trace/trace_sched_switch.c
> > > index e4fbcc3bede5..210c74dc
locating the other array.
>
> Cc: sta...@vger.kernel.org
> Fixes: 939c7a4f04fcd ("tracing: Introduce saved_cmdlines_size file")
> Signed-off-by: Steven Rostedt (Google)
Reviewed-by: Tim Chen
> ---
> kernel/trace/trace.c | 73 +---
x27;t need to be allocated.
This patch does make better use of the extra space and make the
previous change better.
Reviewed-by: Tim Chen
>
> Link:
> https://lore.kernel.org/linux-trace-kernel/20240212174011.06821...@gandalf.local.home/
>
> Signed-off-by: Steven Rostedt (Goo
ocating the other array.
The change looks good to me code wise. But it seems like we are still
overallocating as we can now accommodate 8000 comms when 128
was asked for.
Wonder if we can reduce the default ask to 127 comm so we don't have to
go to the next page order?
Tim
n reduce the number of if statements to make the logic
simpler. Something like
if (!indirect)
return __sgx_encl_get_backing(encl, page_index, backing);
encl_memcg = sgx_encl_get_mem_cgroup(encl);
memcg = set_active_memcg(encl_memcg);
ret = __sgx_encl_get_backing(encl, page_index, backing);
set_active_memcg(memcg);
mem_cgroup_put(encl_memcg);
> return ret;
Tim
u, cpus)
> + WRITE_ONCE(per_cpu(cpufreq_pressure, cpu), pressure);
Seems like the pressure value computed from the first CPU applies to all CPU.
Will this be valid for non-homogeneous CPUs that could have different
max_freq and max_capacity?
Tim
On 3/23/21 4:21 PM, Song Bao Hua (Barry Song) wrote:
>>
>> On 3/18/21 9:16 PM, Barry Song wrote:
>>> From: Tim Chen
>>>
>>> There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce
>>> is shared among a cluster of cores instead of be
t the tier level. Will appreciate feedbacks from folks who have
insights on how such NUMA based control interface will work, so we
at least agree here in order to move forward.
Tim
l in the other thread). That interface should
satisfy the hard constraint you want to place on the low priority
jobs.
Tim
make these assumptions. Though the usability
> will be more difficult. Greg (CCed) has some ideas on making it better
> and we will share our proposal after polishing it a bit more.
>
I am still trying to understand how a numa centric control actually
work. Putting limits on every numa node for each cgroup
seems to make the system configuration quite complicated. Looking
forward to your proposal so I can better understand that perspective.
Tim
take back the excess top tier
> memory use of such jobs.
>
> I have some thoughts on NUMA node limits which I will share in the other
> thread.
>
Shakeel,
Look forward to the proposal on NUMA node limits. Which thread are
you going to post it? Want to make sure I didn't miss it.
Tim
On 4/13/21 6:04 PM, Huang, Ying wrote:
> Tim Chen writes:
>
>> On 4/12/21 6:27 PM, Huang, Ying wrote:
>>
>>>
>>> This isn't the commit that introduces the race. You can use `git blame`
>>> find out the correct commit. For this it'
I suggest to merge 1/5 and 2/5 to make it easy to get the full
> picture.
I'll suggest make fix to do_swap_page race with get/put_swap_device
as a first patch. Then the per_cpu_ref stuff in patch 1 and patch 2 can
be combined together.
Tim
On 4/13/21 3:45 AM, Song Bao Hua (Barry Song) wrote:
>
>
>
> Right now in the main cases of using wake_affine to achieve
> better performance, processes are actually bound within one
> numa which is also a LLC in kunpeng920.
>
> Probably LLC=NUMA is also true for X
quot; for them.
With node priorities, how would the system reserve enough
high performance memory for those performance critical task cgroup?
By priority, do you mean the order of allocation of nodes for a cgroup?
Or you mean that all the similar performing memory node will be grouped in
the same priority?
Tim
=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73f
>> 18.502 ( ): probe:update_blocked_averages:(810cf070)
>> cpu=2 jiffies=0x1004fb740
>>
>
> I don't know exactly what you track with "next_balance=" in
It is the rq->next_balance value as we enter the newidle_balance function.
> probe:newidle_balance but it always starts with the same value
> 0x1004fb76c in the future to finish with a value 0x1004fb731 in the
> past.
This indeed is odd as the next_balance should move forward and not backward.
> This would mean that a load balance is needed during the next
> tick which explains why we can see then the
> probe:update_blocked_averages for each tick.
Will try to debug and find out why the next_balance has gone backwards
next time I get access to the test system.
>
> Also could you check if the tick is stopped when idle. When the
> predicted idle time is short and the next wake is expected to happen
> before the next tick, the tick is not stopped.
>
Will do.
Tim
On 4/9/21 1:42 AM, Miaohe Lin wrote:
> On 2021/4/9 5:34, Tim Chen wrote:
>>
>>
>> On 4/8/21 6:08 AM, Miaohe Lin wrote:
>>> When I was investigating the swap code, I found the below possible race
>>> window:
>>>
>&
b73f
18.036 ( ): probe:newidle_balance:(810d2470)
this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73f
18.040 ( ): probe:newidle_balance:(810d2470)
this_rq=0x88fe7f8aae00 next_balance=0x1004fb731 jiffies=0x1004fb73f
18.502 ( ): probe:update_blocked_averages:(810cf070) cpu=2
jiffies=0x1004fb740
Thanks for taking a look.
Tim
neficial.
Did you encounter a real use case where you see a problem with swapoff?
The delay in swapoff is primarily in try_to_unuse to bring all
the swapped off pages back into memory. Synchronizing with other
CPU for paging in probably is a small component in overall scheme
of things.
Thanks.
Tim
On 4/6/21 2:08 AM, Michal Hocko wrote:
> On Mon 05-04-21 10:08:24, Tim Chen wrote:
> [...]
>> To make fine grain cgroup based management of the precious top tier
>> DRAM memory possible, this patchset adds a few new features:
>> 1. Provides memory monitors on the amount
On 4/7/21 7:02 AM, Vincent Guittot wrote:
> Hi Tim,
>
> On Wed, 24 Mar 2021 at 17:05, Tim Chen wrote:
>>
>>
>>
>> On 3/24/21 6:44 AM, Vincent Guittot wrote:
>>> Hi Tim,
>>
>>>
>>> IIUC your problem, we call update_blocked_aver
For each memory cgroup, account its usage of the
top tier memory at the time a top tier page is assigned and
uncharged from the cgroup.
Signed-off-by: Tim Chen
---
include/linux/memcontrol.h | 1 +
mm/memcontrol.c| 39 +-
2 files changed, 39
Detect during page allocation whether free toptier memory is low.
If so, wake up kswapd to reclaim memory from those mem cgroups
that have exceeded their limit.
Signed-off-by: Tim Chen
---
include/linux/mmzone.h | 3 +++
mm/page_alloc.c| 2 ++
mm/vmscan.c| 2 +-
3 files
Update the toptier_scale_factor via sysctl. This variable determines
when kswapd wakes up to recalaim toptier memory from those mem cgroups
exceeding their toptier memory limit.
Signed-off-by: Tim Chen
---
include/linux/mm.h | 4
include/linux/mmzone.h | 2 ++
kernel/sysctl.c
eded their
toptier memory soft limit by deomoting the top tier pages to
lower memory tier.
Signed-off-by: Tim Chen
---
Documentation/admin-guide/sysctl/vm.rst | 12 +
include/linux/mmzone.h | 2 +
mm/page_alloc.c | 14 +
m
Add toptier relcaim type in mem_cgroup_soft_limit_reclaim().
This option reclaims top tier memory from cgroups in the order of its
excess usage of top tier memory.
Signed-off-by: Tim Chen
---
include/linux/memcontrol.h | 9 ---
mm/memcontrol.c| 48
Track the global top tier memory usage stats. They are used as the basis of
deciding when to start demoting pages from memory cgroups that have exceeded
their soft limit. We start reclaiming top tier memory when the total
top tier memory is low.
Signed-off-by: Tim Chen
---
include/linux
allow returning the cgroup that has the largest exceess usage
of toptier memory.
Signed-off-by: Tim Chen
---
include/linux/memcontrol.h | 9 +++
mm/memcontrol.c| 152 +++--
2 files changed, 122 insertions(+), 39 deletions(-)
diff --git a/include
Define a per node soft_limit_top_tier red black tree that sort and track
the cgroups by each group's excess over its toptier soft limit. A cgroup
is added to the tree if it has exceeded its top tier soft limit and it
has used pages on the node.
Signed-off-by: Tim Chen
---
mm/memcontrol.c
In memory cgroup's sysfs, report the memory cgroup's usage
of top tier memory in a new field: "toptier_usage_in_bytes".
Signed-off-by: Tim Chen
---
mm/memcontrol.c | 8
1 file changed, 8 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index fe7bb8
For each memory cgroup, define a soft memory limit on
its top tier memory consumption. Memory cgroups exceeding
their top tier limit will be selected for demotion of
their top tier memory to lower tier under memory pressure.
Signed-off-by: Tim Chen
---
include/linux/memcontrol.h | 1 +
mm
/expensive memory lives in the top tier of the memory
hierachy and it is a precious resource that needs to be accounted and
managed on a memory cgroup basis.
Define the top tier memory as the memory nodes that don't have demotion
paths into it from higher tier memory.
Signed-off-by: Tim
es in lieu of discard
and
[PATCH 0/6] [RFC v6] NUMA balancing: optimize memory placement for memory
tiering system
It is part of a larger patchset. You can play with the complete set of patches
using the tree:
https://git.kernel.org/pub/scm/linux/kernel/git/vishal/tiering.git/log/?h=tiering-0.71
ports
- onboard 802.11ac WiFi / BT
- microSD socket
- miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
- Wide range DC power input
- 802.3at PoE
Signed-off-by: Tim Harvey
Reviewed-by: Fabio Estevam
---
v3:
- remove always-on from regulators that don't have on/off control
-
ports
- onboard 802.11ac WiFi / BT
- microSD socket
- miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
- Wide range DC power input
- 802.3at PoE
Acked-by: Rob Herring
Signed-off-by: Tim Harvey
Reviewed-by: Fabio Estevam
---
v3:
- add reviewed-by
v2:
- add Rob's Ack
On 3/24/21 6:44 AM, Vincent Guittot wrote:
> Hi Tim,
>
> IIUC your problem, we call update_blocked_averages() but because of:
>
> if (this_rq->avg_idle < curr_cost + sd->max_newidle_lb_cost) {
> update_nex
Fix a typo in comment.
Signed-off-by: Tim Yang
---
kernel/kcov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kcov.c b/kernel/kcov.c
index 80bfe71bbe13..6f59842f2caf 100644
--- a/kernel/kcov.c
+++ b/kernel/kcov.c
@@ -527,7 +527,7 @@ static int kcov_get_mode
On 3/18/21 9:16 PM, Barry Song wrote:
> From: Tim Chen
>
> There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce
> is shared among a cluster of cores instead of being exclusive
> to one single core.
>
> To prevent oversubscription of L2 cache, load should
load_balance(). If we don't do any load balance
in the code path,
we can let the idle load balancer update the blocked averages lazily.
Something like the following perhaps on top of Vincent's patch? We haven't
really tested
this change yet but want to see if this change makes se
ports
- onboard 802.11ac WiFi / BT
- microSD socket
- miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
- Wide range DC power input
- 802.3at PoE
Acked-by: Rob Herring
Signed-off-by: Tim Harvey
---
v2:
- add Rob's Acked-by
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1
ports
- onboard 802.11ac WiFi / BT
- microSD socket
- miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
- Wide range DC power input
- 802.3at PoE
Signed-off-by: Tim Harvey
---
v2:
- fixed issues reported by check_dtbs:
- add missing GSC #address-cells and #size-cells
- use common
'll just drop it due to the
> > > following
> > arguments:
> > > 1. all the clocks are gated by default 2. all resets are deasserted by
> > > default 3. when blk_ctl goes down, all the consumers go down. (all
> > > have the same PD)
> > >
> > > From 1 and 2 results the IP will not be running and from 3 results
> > > the HW state of every IP becomes HW init state.
> >
> > Are there any plans to continue this work? As BLK-CTL it is not only
> > relevant
> > for the i.MX8MP, but also for i.MX8MM and i.MX8MN, it would be nice to get
> > this ready in order to prepare for proper graphics/display support.
> >
>
> Before continuing this work, we need to find out a way to resolve the cycling
> dependency issue between power domain and blk-ctrl.
> it is indeed introduced some troubles in NXP latest internal release when the
> blk-ctrl driver is added.
>
Jacky,
Any update on this? This is still blocking several drivers and major
functionality of the i.MX8 SoC's in mainline and I would hope this
would be a top priority for NXP.
Best regards,
Tim
> It seems sensible the more CPU we get in the cluster, the more
> we need the kernel to be aware of its existence.
>
> Tim, it is possible for you to bring up the cpu_cluster_mask and
> cluster_sibling for x86 so that the topology can be represented
> in sysfs and be use
'On Tue, Mar 9, 2021 at 9:34 PM wrote:
>
> On 3/10/21 12:59 AM, Michael Walle wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Hi Tim,
> >
> > Am 2021-03-09 23:00, schrieb Tim Har
On Tue, Mar 9, 2021 at 2:59 PM Michael Walle wrote:
>
> Hi Tim,
>
> Am 2021-03-09 23:00, schrieb Tim Harvey:
> > Document the compatible value for the Fujitsu MB85RS4MT SPI
> > FRAM EEPROM device so that it can be used in DTS files.
> >
> > This is a 512KiB FRA
ports
- onboard 802.11ac WiFi / BT
- microSD socket
- miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
- Wide range DC power input
- 802.3at PoE
Signed-off-by: Tim Harvey
---
arch/arm64/boot/dts/freescale/Makefile|1 +
.../dts/freescale/imx8mm-venice-gw7901.dts| 1008
Add support for the Fujitsu MB85RS4MT SPI FRAM EEPROM device.
This is a 512KiB FRAM EEPROM.
Signed-off-by: Tim Harvey
---
drivers/mtd/spi-nor/fujitsu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/fujitsu.c b/drivers/mtd/spi-nor/fujitsu.c
index e385d93e756c
Document the compatible value for the Fujitsu MB85RS4MT SPI
FRAM EEPROM device so that it can be used in DTS files.
This is a 512KiB FRAM EEPROM.
Signed-off-by: Tim Harvey
---
Documentation/devicetree/bindings/eeprom/at25.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation
ports
- onboard 802.11ac WiFi / BT
- microSD socket
- miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
- Wide range DC power input
- 802.3at PoE
Signed-off-by: Tim Harvey
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a
On 3/5/21 1:11 AM, Michal Hocko wrote:
> On Thu 04-03-21 09:35:08, Tim Chen wrote:
>>
>>
>> On 2/18/21 11:13 AM, Michal Hocko wrote:
>>
>>>
>>> Fixes: 4e41695356fb ("memory controller: soft limit reclaim on contention")
>>> Acked-
bit more, I realize that there is a chance that the
removed
next_mz could be inserted back to the tree from a memcg_check_events
that happen in between. So we need to make sure that the next_mz
is indeed off the tree and update the excess value before adding it
back. Update the patch to the pa
On 3/2/21 2:30 AM, Peter Zijlstra wrote:
> On Tue, Mar 02, 2021 at 11:59:40AM +1300, Barry Song wrote:
>> From: Tim Chen
>>
>> There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce
>> is shared among a cluster of cores instead of being exclusive
>&g
per-memcg, aren't they?
> __this_cpu_read(memcg->vmstats_percpu->targets[target]);
> [...]
> __this_cpu_write(memcg->vmstats_percpu->targets[target], next);
>
You are right. My previous reasoning is incorrect as the sampling is done per
memcg.
I'll do some additional debugging on why memcg is not on the tree.
Tim
On 2/24/21 3:53 AM, Michal Hocko wrote:
> On Mon 22-02-21 11:48:37, Tim Chen wrote:
>>
>>
>> On 2/22/21 11:09 AM, Michal Hocko wrote:
>>
>>>>
>>>> I actually have tried adjusting the threshold but found that it doesn't
>>>&
On 2/22/21 9:41 AM, Tim Chen wrote:
>
>
> On 2/22/21 12:40 AM, Michal Hocko wrote:
>> On Fri 19-02-21 10:59:05, Tim Chen wrote:
> occurrence.
>>>>
>>>> Soft limit is evaluated every THRESHOLDS_EVENTS_TARGET *
>>>> SOFTLIMIT_EVENTS_TARG
next time it exceeds the soft limit.
As long as we are doing sampling update, this problem is baked in unless we
add the check to make sure that the memcg is subjected to page reclaim as long
as it exceeds the soft limit.
Tim
On 2/22/21 11:09 AM, Michal Hocko wrote:
> On Mon 22-02-21 09:41:00, Tim Chen wrote:
>>
>>
>> On 2/22/21 12:40 AM, Michal Hocko wrote:
>>> On Fri 19-02-21 10:59:05, Tim Chen wrote:
>> occurrence.
>>>>>
>>&
node as well.
>*/
> if (ug->memcg != page_memcg(page) ||
> (!cgroup_subsys_on_dfl(memory_cgrp_subsys) &&
>ug->memcg->soft_limit != PAGE_COUNTER_MAX &&
>ug->nid != page_to_nid(page)))
>
Johannes,
Thanks for your feedback. Since Michal has concerns about the overhead
this patch could incur, I think we'll hold the patch for now. If later
on Michal think that this patch is a good idea, I'll incorporate these
changes you suggested.
Tim
up?
>
> I would rather drop it. The less the soft limit reclaim code is spread
> around the better.
>
Let's drop patch 3 then. I find patch 2 is the most critical one in this
series.
Without that patch some cgroups exceeds the soft limit excess very badly.
Tim
On 2/22/21 12:40 AM, Michal Hocko wrote:
> On Fri 19-02-21 10:59:05, Tim Chen wrote:
occurrence.
>>>
>>> Soft limit is evaluated every THRESHOLDS_EVENTS_TARGET *
>>> SOFTLIMIT_EVENTS_TARGET.
>>> If all events correspond with a newly charged memory an
On 2/19/21 10:59 AM, Tim Chen wrote:
>
>
> On 2/19/21 1:11 AM, Michal Hocko wrote:
>>
>> Soft limit is evaluated every THRESHOLDS_EVENTS_TARGET *
>> SOFTLIMIT_EVENTS_TARGET.
>> If all events correspond with a newly charged memory and the last event
>>
ink it is still a good idea to add patch 3 to
restrict the uncharge update in page batch of the same node and cgroup?
I am okay with dropping patch 3 and let the inaccuracies in the ordering
of soft limit tree be cleared out by an occasional soft reclaim.
These inaccuracies will still be there even with patch 3 fix due
to the memcg event sampling. Patch 3 does help to keep the soft reclaim
tree ordering more up to date.
Thanks.
Tim
On 2/19/21 1:11 AM, Michal Hocko wrote:
> On Wed 17-02-21 12:41:35, Tim Chen wrote:
>> Memory is accessed at a much lower frequency
>> for the second cgroup. The memcg event update was not triggered for the
>> second cgroup as the memcg event update didn't hap
On 2/18/21 11:13 AM, Michal Hocko wrote:
> On Thu 18-02-21 10:30:20, Tim Chen wrote:
>>
>>
>> On 2/18/21 12:24 AM, Michal Hocko wrote:
>>
>>>
>>> I have already acked this patch in the previous version along with Fixes
>>> tag. It seems th
d patch 1 with the fixes tag
for commit 4e41695356fb ("memory controller: soft limit reclaim on contention")
and if there are any changes I should make for patch 2.
Thanks.
Tim
memory
soft limit.
Reviewed-by: Ying Huang
Signed-off-by: Tim Chen
---
mm/memcontrol.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d72449eeb85a..8bddee75f5cb 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6804,6 +6804,7
-by: Tim Chen
---
mm/memcontrol.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a51bf90732cb..d72449eeb85a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -985,15 +985,22 @@ static bool mem_cgroup_event_ratelimit(struct
this patch.
Thanks.
Tim
Changelog:
v2
1. Do soft limit tree uncharge update in batch of the same node only
for v1 cgroups that have a soft limit. Batching in nodes is only
relevant for cgroup v1 that has per node soft limit tree.
Tim Chen (3):
mm: Fix dropped memcg from mem cgroup soft limit
cgroup exceeded its soft limit. Fix the logic and put the mem
cgroup back on the tree when page reclaim failed for the mem cgroup.
Reviewed-by: Ying Huang
Signed-off-by: Tim Chen
---
mm/memcontrol.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm
; single patchset that accommodates both use cases.
>
> Hi Tim, Agreed on this.
> hopefully the RFC v4 I am preparing will cover your case.
>
Barry,
I've taken a crack at it. Attached is a patch on top of your
v3 patches to implement L2 cluster sche
On 2/9/21 2:22 PM, Johannes Weiner wrote:
> Hello Tim,
>
> On Tue, Feb 09, 2021 at 12:29:47PM -0800, Tim Chen wrote:
>> @@ -6849,7 +6850,9 @@ static void uncharge_page(struct page *page, struct
>> uncharge_gather *ug)
>> * exclusive access to the page.
>
, with each batch of
pages all in the same mem cgroup and memory node. An update is issued for
the batch of pages of a node collected till now whenever we encounter
a page belonging to a different node.
Reviewed-by: Ying Huang
Signed-off-by: Tim Chen
---
mm/memcontrol.c | 6 +-
1 file
-by: Tim Chen
---
mm/memcontrol.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a51bf90732cb..d72449eeb85a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -985,15 +985,22 @@ static bool mem_cgroup_event_ratelimit(struct
cgroup exceeded its soft limit. Fix the logic and put the mem
cgroup back on the tree when page reclaim failed for the mem cgroup.
Reviewed-by: Ying Huang
Signed-off-by: Tim Chen
---
mm/memcontrol.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm
During testing of tiered memory management based on memory soft limit, I found
three
issues with memory management using cgroup based soft limit in the mainline
code.
Fix the issues with the three patches in this series.
Tim Chen (3):
mm: Fix dropped memcg from mem cgroup soft limit tree
On 1/8/21 7:12 AM, Morten Rasmussen wrote:
> On Thu, Jan 07, 2021 at 03:16:47PM -0800, Tim Chen wrote:
>> On 1/6/21 12:30 AM, Barry Song wrote:
>>> ARM64 server chip Kunpeng 920 has 6 clusters in each NUMA node, and each
>>> cluster has 4 cpus. All clusters sha
che sched domain, sans the idle cpu selection on wake up code. It is
similar enough in concept to Barry's patch that we should have a
single patchset that accommodates both use cases.
Thanks.
Tim
>From e0e7e42e1a033c9634723ff1dc80b426deeec1e9 Mon Sep 17 00:00:00 2001
Message-Id:
In-
Add bindings for the Gateworks Venice Development kit boards with
IMX8MM System on Module.
Signed-off-by: Tim Harvey
---
v5: no changes
v4: no changes
v3: no changes
v2: no changes
---
Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a
ntrol, RS485, RS422
- WiFi/BT
- PCIe Clock generator
- GPS and accelerometer
- Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
- I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
- wide range power supply
Signed-off-by: Tim Harvey
---
v5:
- fixed typo/grammar in commit log (s/con
On Mon, Jan 4, 2021 at 4:36 AM Krzysztof Kozlowski wrote:
>
> On Wed, Dec 30, 2020 at 09:58:43AM -0800, Tim Harvey wrote:
> > The Gateworks Venice GW71xx-0x/GW72xx-0x/GW73xx-0x are development
> > kits comprised of a GW700x SoM and a Baseboard. Future SoM's such
> &
troll, RS485, RS422
- WiFi/BT
- PCIe Clock generator
- GPS and accelerometer
- Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
- I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
- wide range power supply
Signed-off-by: Tim Harvey
---
v4:
- replace underscore with hyphen for gpio-keys
Add bindings for the Gateworks Venice Development kit boards with
IMX8MM System on Module.
Signed-off-by: Tim Harvey
---
v4: no changes
v3: no changes
v2: no changes
---
Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation
On Wed, Dec 30, 2020 at 5:14 AM Mark Brown wrote:
>
> On Tue, Dec 29, 2020 at 08:23:00AM -0800, Tim Harvey wrote:
> > On Tue, Dec 29, 2020 at 5:06 AM Mark Brown wrote:
>
> > > I can't understand what this commit message is trying to say, sorry.
> > > Which b
On Tue, Dec 29, 2020 at 5:06 AM Mark Brown wrote:
>
> On Mon, Dec 28, 2020 at 01:45:51PM -0800, Tim Harvey wrote:
>
> > Some interrupt controllers may not de-assert their interrupt if
> > bits are set when acknowledging the bits that caused the interrupt.
>
> > Take
troll, RS485, RS422
- WiFi/BT
- PCIe Clock generator
- GPS and accelerometer
- Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
- I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
- wide range power supply
Signed-off-by: Tim Harvey
---
v3:
- fix gpio controller node name
- add rtc no
Add bindings for the Gateworks Venice Development kit boards with
IMX8MM System on Module.
Signed-off-by: Tim Harvey
---
v3: no changes
v2: no changes
---
Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm
1 - 100 of 2124 matches
Mail list logo
