On Wed, Feb 03, 2021 at 09:16:10AM -0800, Ben Widawsky wrote:
> On 21-02-02 15:57:03, Dan Williams wrote:
> > On Tue, Feb 2, 2021 at 3:51 PM Ben Widawsky wrote:
> > >
> > > On 21-02-01 13:28:48, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Jan 29, 2021 at 04:24:37PM -0800, Ben Widawsky wrote:
> >
"sdam->pdev" is uninitialized and it is used to print error logs.
Fix it. Since device pointer can be used from sdam_config, use it
directly thereby removing pdev pointer.
Cc: sta...@vger.kernel.org
Signed-off-by: Subbaraman Narayanamurthy
---
drivers/nvmem/qcom-spmi-sdam.c | 7 +++
1 file
On Wed, Feb 3, 2021 at 7:43 AM Tudor Ambarus
wrote:
>
> These are all "early clocks" that require initialization just at
> of_clk_init() time. Use CLK_OF_DECLARE() to declare them.
>
> This also fixes a problem that was spotted when fw_devlink was
> set to 'on' by default: the boards failed to
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath. Convert it to use
seqnum_ops.
event_seq atomic_t variables are atomic counters. Convert them to use
seqnum_ops.
Signed-off-by: Shuah Khan
---
Hey Heiko,
I have tested your patch set on my nanoPC-T4, here is a complete log
with:
- relevant kernel log entries
- system information
- media ctl output
- sysfs entry information
https://paste.debian.net/1183874/
Additionally, to your patchset I have applied the following patches:
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath. Convert it to use
seqnum_ops.
event_seq atomic_t variables are atomic counters. Convert them to use
seqnum_ops.
Signed-off-by: Shuah Khan
---
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath.
Convert uevent_seqnum atomic counter to use seqnum_ops.
Signed-off-by: Shuah Khan
---
include/linux/kobject.h | 3 ++-
kernel/ksysfs.c | 3 ++-
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath.
Convert seqno atomic counter to use seqnum_ops.
Signed-off-by: Shuah Khan
---
drivers/acpi/apei/ghes.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
Sequence Number api provides interfaces for unsigned atomic up counters.
There are a number of atomic_t usages in the kernel where atomic_t api
is used for counting sequence numbers and other statistical counters.
Several of these usages, convert atomic_read() and atomic_inc_return()
return
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath.
Convert seqno atomic counter to use seqnum_ops.
Signed-off-by: Shuah Khan
---
drivers/acpi/acpi_extlog.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
On Thu 28-01-21 22:39:46, Randy Dunlap wrote:
> On 1/28/21 9:00 PM, bingjingc wrote:
> > From: BingJing Chang
> >
> > Fix existing issues at the kernel-doc markups
> >
> > Signed-off-by: BingJing Chang
> > ---
> > lib/parser.c | 22 +++---
> > 1 file changed, 11 insertions(+),
Sequence Number api provides interfaces for unsigned atomic up counters.
There are a number of atomic_t usages in the kernel where atomic_t api
is used for counting sequence numbers and other statistical counters.
Several of these usages, convert atomic_read() and atomic_inc_return()
return
On Wed, Feb 3, 2021 at 10:00 AM Gabriel Krisman Bertazi
wrote:
>
> Linus Torvalds writes:
>
> > On Sun, Jan 31, 2021 at 3:35 PM Linus Torvalds
> > wrote:
> >>
> >> I wonder if the simple solution is to just
> >>
> >> (a) always set one of the SYSCALL_WORK_EXIT bits on the child in
> >> ptrace
On Wed, Feb 3, 2021 at 10:00 AM Gabriel Krisman Bertazi
wrote:
>
> Does the patch below follows your suggestion? I'm setting the
> SYSCALL_WORK shadowing TIF_SINGLESTEP every time, instead of only when
> the child is inside a system call. Is this acceptable?
Looks sane to me.
My main worry
task_user_regset_view() has nonsensical semantics, but those semantics
appear to be relied on by existing users of PTRACE_GETREGSET and
PTRACE_SETREGSET. (See added comments in this patch for details.)
It shouldn't be used for PTRACE_GETREGS or PTRACE_SETREGS, though. A
native 64-bit ptrace()
On Fri 29-01-21 12:51:48, bingjingc wrote:
> From: BingJing Chang
>
> The uid/gid (unsigned int) of a domain user may be larger than INT_MAX.
> The parse_options of isofs and udf will return 0, and mount will fail
> with -EINVAL. These patches try to handle large user and group ID.
>
> BingJing
Add writeq() and readq() for 64 bits architures support.
Supporting these two functions will allow the write or the read of eDMA
64 bits registers at once instead of having two consecutive operations.
Also, this improvement will allow the PCI optimization transaction
messages, which will
In the driver code structure, I tried to keep the code style consistency
by writing the write channels instructions first, and then follow by the
read channels instructions, mimicking the hardware implementation.
However, this code style failed in some cases. This patch fixes that and
no
The latest eDMA IP development implements a Vendor-Specific Extended
Capability that contains the eDMA BAR, offset, map format, and the
number of read/write channels available.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 20 ---
Add pci_find_vsec_capability() that crawls through the device config
space searching in all Vendor-Specific Extended Capabilities for a
particular capability ID.
Vendor-Specific Extended Capability (VSEC) is a PCIe capability (acts
like a wrapper) specified by PCI-SIG that allows the vendor to
On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:
> >> Jakub, Dave, Adding you both to get your reviews on this series. I've
> >> provided an explanation above and in the previous iteration [1].
> >
> >Let's be clear what the review would be for. Yet another QMI chardev
> >or the
On 28/01/2021 02:03, Herbert Xu wrote:
> On Fri, Jan 22, 2021 at 03:09:52PM +0800, Meng Yu wrote:
>> 1. Add ecc curves(P224, P384, P521) for ECDH;
>
> OK I think this is getting unwieldy.
>
> In light of the fact that we already have hardware that supports
> a specific subset of curves, I think
Dear RT folks!
I'm pleased to announce the v5.10.12-rt26 patch set.
Changes since v5.10.12-rt25:
- Updated the "tracing: Merge irqflags + preempt counter." patch to
the version Steven posted for upstream inclusion.
- Update the work-in-progress softirq patch. One difference is that
On Wed, Feb 3, 2021 at 10:49 AM Rob Herring wrote:
>
> On Wed, Feb 3, 2021 at 8:44 AM Andre Przywara wrote:
> >
> > On Wed, 3 Feb 2021 15:15:19 +0100
> > Michal Simek wrote:
> >
> > > On 2/3/21 3:12 PM, Rob Herring wrote:
> > > > On Wed, Feb 3, 2021 at 1:01 AM Michal Simek
> > > > wrote:
> >
Add support for the HDMA feature.
This new feature enables the current eDMA IP to use a deeper prefetch
of the linked list, which reduces the algorithm execution latency
observed when loading the elements of the list, causing more stable
and higher data transfer.
Signed-off-by: Gustavo Pimentel
Fix comments offset characters' alignment to follow the same structure
of similar comments.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-v0-regs.h | 214 +-
1 file changed, 107 insertions(+), 107 deletions(-)
diff --git
This patch is only compile-tested.
Signed-off-by: Mathieu Desnoyers
---
include/linux/tracepoint.h | 2 +-
kernel/tracepoint.c| 80 +-
2 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/include/linux/tracepoint.h
On Wed, Feb 03, 2021 at 04:13:21PM +, Joao Martins wrote:
> If check_and_migrate_movable_pages() is meant to migrate unpinned
> pages, then rather than pinning+unpinning+moving, perhaps it would
> be called in __get_user_pages() place where we are walking page
> tables and know if it's a
Collect the time when each allocation is freed, to help with memory
analysis with kdump/ramdump. Add the timestamp also in the page_owner
debugfs file and print it in dump_page().
Having another timestamp when we free the page helps for debugging
page migration issues. For example both alloc and
Move struct dentry variable from static definition (dw-edma-v0-debugfs.c)
into dw_edma struct (dw-edma-core.h)
Also the variable was renamed from base_dir to debugfs.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 2 +-
drivers/dma/dw-edma/dw-edma-core.h
When the driver is compiled as a module and loaded if we try to unload
it, the Kernel shows a crash log. This Kernel crash is due to the
dma_async_device_unregister() call done after deleting the channels,
this patch fixes this issue.
Signed-off-by: Gustavo Pimentel
---
Linus Torvalds writes:
> On Sun, Jan 31, 2021 at 3:35 PM Linus Torvalds
> wrote:
>>
>> I wonder if the simple solution is to just
>>
>> (a) always set one of the SYSCALL_WORK_EXIT bits on the child in
>> ptrace (exactly to catch the child on system call exit)
>>
>> (b) basically revert
On 2/3/21 7:25 AM, Bhaskar Chowdhury wrote:
Normally a patch description is required .
If the patch committer wants to take it as is, the typo
fix LGTM.
> Signed-off-by: Bhaskar Chowdhury
> ---
> arch/sh/kernel/relocate_kernel.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
To keep code consistent, some comments with dma keyword written in lower
case are now in upper case.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c
Reverting the applied patch because it caused a regression on
ARC700 platform (32 bits).
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c
Detected by CoverityScan CID 16555 ("Dereference null return")
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-pcie.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c
b/drivers/dma/dw-edma/dw-edma-pcie.c
index
Add device_prep_interleave_dma() support to Synopsys DMA driver.
This feature implements a similar data transfer mechanism to the
scatter-gather implementation.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 85 ++
Changes the linked list and data blocks offset and sizes to follow the
recommendation given by the hardware team for the IPK solution.
Although the previous data blocks offset and sizes are still valid and
functional, using them that might present some issues related to the IPK
solution, since
In the previous implementation the driver assumes that only existed 2
memory spaces that would be equal distributed amount the write/read
channels.
This might not be the case on some other implementations, therefore this
patches changes this requirement so that each write/read channel has
their
It was added some extra checks to ensure that the driver doesn't try to
use more DMA channels than actually are available in hardware.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 21 +
drivers/dma/dw-edma/dw-edma-core.h | 2 ++
2 files changed,
This patch series adds the HDMA support, as long the IP design has set
the compatible register map parameter, which allows compatibility at
some degree for the existing Synopsys DesignWare eDMA driver that is
already available on the Kernel.
The HDMA "Hyper-DMA" IP is an enhancement of the eDMA
- On Feb 3, 2021, at 11:05 AM, rostedt rost...@goodmis.org wrote:
> From: "Steven Rostedt (VMware)"
>
> The list of tracepoint callbacks is managed by an array that is protected
> by RCU. To update this array, a new array is allocated, the updates are
> copied over to the new array, and
On 2/3/2021 4:22 AM, Bjorn Andersson wrote:
On Fri 08 Jan 12:15 CST 2021, Akhil P Oommen wrote:
Please align the $subject prefix with other changes in the same file.
I fixed it up while picking up the patch this time.
Will take of this in future. Thanks, Bjorn.
-Akhil.
Regards,
Bjorn
Add
On Wed, Feb 03, 2021, Paolo Bonzini wrote:
> Looks good! I'll wait for a few days of reviews,
I guess I know what I'm doing this afternoon :-)
> but I'd like to queue this for 5.12 and I plan to make it the default in 5.13
> or 5.12-rc (depending on when I can ask Red Hat QE to give it a
On 2/3/21 7:15 AM, Bhaskar Chowdhury wrote:
>
> s/initialsation/initialisation/
> s/specifiing/specifying/
>
> Signed-off-by: Bhaskar Chowdhury
Hi,
$Subject has a typo/spello.
The 2 fixes below look good (as explained in the patch description),
but:
can you explain the 3 changes below that
On 2/3/21 4:50 AM, Yang Li wrote:
Eliminate the following coccicheck warning:
./drivers/pwm/pwm-lpc18xx-sct.c:292:2-3: Unneeded semicolon
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
Acked-by: Vladimir Zapolskiy
--
Best wishes,
Vladimir
On Tue, Feb 02, 2021 at 09:40:40PM +, Mike Leach wrote:
> The current fixed metadata version format (version 0), means that adding
> metadata parameter items renders files from a previous version of perf
> unreadable. Per CPU parameters appear in a fixed order, but there is no
> field to
Em Wed, 3 Feb 2021 08:34:21 -0600
Rob Herring escreveu:
> On Wed, Feb 3, 2021 at 1:02 AM Mauro Carvalho Chehab
> wrote:
> >
> > From: Manivannan Sadhasivam
> >
> > Add support for HiSilicon Kirin 970 (hi3670) SoC PCIe controller, based
> > on Synopsys DesignWare PCIe controller IP.
> >
> >
Em Wed, 3 Feb 2021 16:18:01 +0100
Krzysztof Wilczyński escreveu:
> Hi Mauro,
>
> Thank you for working on this!
>
> > @@ -151,8 +152,10 @@ struct kirin_pcie {
> > struct clk *phy_ref_clk;
> > struct clk *pcie_aclk;
> > struct clk *pcie_aux_clk;
> > - int
On 1/22/21 2:30 PM, Thiago Jung Bauermann wrote:
Hi Lakshmi,
Lakshmi Ramasubramanian writes:
IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function. In error code paths
> Can you pretty please not line-wrap console output? It's unreadable.
GMail doesn't make it easy, I'll send a link to a pastebin next time.
Let me know if you'd like me to regenerate the decoded stack.
> > edfd9b7838ba5e47f19ad8466d0565aba5c59bf0 is the first bad commit
> > commit
On Wed, Feb 3, 2021 at 4:40 AM Paolo Bonzini wrote:
>
> On 02/02/21 19:57, Ben Gardon wrote:
> >
> > - write_lock(>kvm->mmu_lock);
> > +
> > + if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
> > + read_lock(>kvm->mmu_lock);
> > + else
> > +
On 1/22/21 2:31 PM, Thiago Jung Bauermann wrote:
Lakshmi Ramasubramanian writes:
IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function. This buffer is not freed before
On 2/3/21 7:01 AM, Bhaskar Chowdhury wrote:
>
> s/messge/message/ ..two different lines
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
Thanks.
> ---
> drivers/crypto/qat/qat_common/adf_vf2pf_msg.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On 2/3/21 1:07 AM, Chunyan Zhang wrote:
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 192ef8f61310..99e7712f3903 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -408,4 +408,16 @@ config VIRTIO_IOMMU
>
> Say Y here if you intend to run this
Hi,
On Tue, 2 Feb 2021 at 16:39, Leo Yan wrote:
>
> After support the PID tracing for the kernel in EL1 or EL2, the usage
> gets more complicated.
>
> This patch gives description for the PMU formats of contextID configs,
> this can help users to understand how to control the knobs for PID
>
On Wed, Feb 03, 2021 at 04:52:39PM +0900, Masahiro Yamada wrote:
> Sedat Dilek noticed duplicated debug flags passed when building C
> files with CONFIG_DEBUG_INFO.
>
> I do not know much about his build environment, but yes, Kbuild
> recurses to the top Makefile with some build targets. For
On Wed, Feb 3, 2021 at 9:07 AM Yonghong Song wrote:
>
>
>
> On 2/2/21 5:50 AM, Brendan Jackman wrote:
> > When BPF_FETCH is set, atomic instructions load a value from memory
> > into a register. The current verifier code first checks via
> > check_mem_access whether we can access the memory, and
On Wed, 03 Feb 2021 18:34:12 +0100,
Anton Yakovlev wrote:
>
> Hi Takashi,
>
>
> On 03.02.2021 17:59, Takashi Iwai wrote:
> > On Tue, 02 Feb 2021 00:18:09 +0100,
> > Anton Yakovlev wrote:
> +/**
> + * virtsnd_reset_fn() - Kernel worker's function to reset the device.
> + * @work:
Hi Takashi,
On 03.02.2021 17:59, Takashi Iwai wrote:
On Tue, 02 Feb 2021 00:18:09 +0100,
Anton Yakovlev wrote:
+/**
+ * virtsnd_reset_fn() - Kernel worker's function to reset the device.
+ * @work: Reset device work.
+ *
+ * Context: Process context.
+ */
+static void virtsnd_reset_fn(struct
On Wed, 3 Feb 2021 at 18:09, Qais Yousef wrote:
>
> On 01/29/21 18:27, Vincent Guittot wrote:
> > The patch below moves the update of the blocked load of CPUs outside
> > newidle_balance().
> >
> > Instead, the update is done with the usual idle load balance update. I'm
> > working on an
> >
On Wed, Feb 03, 2021 at 05:05:43PM +0100, Pavel Machek wrote:
> On Mon 2021-02-01 11:52:12, Dmitry Vyukov wrote:
> Could we please get common prefix (like syzbot: KASAN:) so that
> the bulk of emails is easier to remove?
There are several bots testing on the kernel, maybe we should give a
ell
>> Date: Tue, 2 Feb 2021 19:49:00 +1100
>> Subject: [PATCH] make is_pinnable_page a macro
>>
>> As it is currently defined before page_to_section() which it needs.
>>
>> Signed-off-by: Stephen Rothwell
>
> I still see the same problem in next-20210203,
On Wed, Feb 3, 2021 at 6:14 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
> >
> > On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> > >
> > > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John
> > > wrote:
> > > >
> > > > >>Uh, that doesn't work. If you want
On 2/3/21 12:12 PM, Mark Rutland wrote:
On Wed, Feb 03, 2021 at 09:26:45AM +0100, Julien Thierry wrote:
On 2/2/21 11:17 AM, Mark Rutland wrote:
On Wed, Jan 20, 2021 at 06:17:41PM +0100, Julien Thierry wrote:
Aarch64 instruction set encoding and decoding logic can prove useful
for some
On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
>
> On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jan 25, 2021 at 03:49:01PM -0800, Stephen Boyd wrote:
> > > > Lockdep complains about an AA deadlock when
Em Wed, 3 Feb 2021 13:46:20 +
Mark Brown escreveu:
> On Wed, Feb 03, 2021 at 08:01:53AM +0100, Mauro Carvalho Chehab wrote:
>
> > + reg = devm_regulator_get_optional(dev, "pci");
> > + if (IS_ERR_OR_NULL(reg)) {
> > + if (PTR_ERR(reg) == -EPROBE_DEFER)
> > +
The test measures the kernel's signal delivery with different (enough vs.
insufficient) stack sizes.
Signed-off-by: Chang S. Bae
Reviewed-by: Len Brown
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: linux-kselft...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Changes from v3:
* Revised
Signal frames do not have a fixed format and can vary in size when a number
of things change: support XSAVE features, 32 vs. 64-bit apps. Add the code
to support a runtime method for userspace to dynamically discover how large
a signal stack needs to be.
Introduce a new variable, max_frame_size,
The kernel pushes context on to the userspace stack to prepare for the
user's signal handler. When the user has supplied an alternate signal
stack, via sigaltstack(2), it is easy for the kernel to verify that the
stack size is sufficient for the current hardware context.
Check if writing the
Historically, signal.h defines MINSIGSTKSZ (2KB) and SIGSTKSZ (8KB), for
use by all architectures with sigaltstack(2). Over time, the hardware state
size grew, but these constants did not evolve. Today, literal use of these
constants on several architectures may result in signal stack overflow,
During signal entry, the kernel pushes data onto the normal userspace
stack. On x86, the data pushed onto the user stack includes XSAVE state,
which has grown over time as new features and larger registers have been
added to the architecture.
MINSIGSTKSZ is a constant provided in the kernel
Move the AT_MINSIGSTKSZ definition to generic Linux from arm64. It is
already used as generic ABI in glibc's generic elf.h, and this move will
prevent future namespace conflicts. In particular, x86 will re-use this
generic definition.
Signed-off-by: Chang S. Bae
Reviewed-by: Len Brown
Cc:
On 01/27/21 19:30, Valentin Schneider wrote:
> Fiddling some more with a TLA+ model of set_cpus_allowed_ptr() & friends
> unearthed one more outstanding issue. This doesn't even involve
> migrate_disable(), but rather affinity changes and execution of the stopper
> racing with each other.
>
> My
Hi!
> > Yes, sounds reasonable. Could we get default intensity of 100% on all
> > channels if nothing else is specified?
> >
> > Or maybe simply "if intensity is not specified, start with 100%, and
> > use explicit =0 if other color is expected".
> >
> Mh, if someone is already using the led
On Wed, Feb 03, 2021 at 10:09:01PM +0530, Sameer Pujar wrote:
> On 2/3/2021 9:49 PM, Mark Brown wrote:
> > On Wed, Feb 03, 2021 at 09:39:34PM +0530, Sameer Pujar wrote:
> > > +int graph_remove(struct platform_device *pdev);
> > I think this needs better namespacing if it's going to be exported.
On Wed, 3 Feb 2021 18:09:27 +0100
Peter Zijlstra wrote:
> On Wed, Feb 03, 2021 at 11:05:31AM -0500, Steven Rostedt wrote:
> > + if (new) {
> > + for (i = 0; old[i].func; i++)
> > + if ((old[i].func != tp_func->func
> > +
On 2021-02-02 15:46, John Garry wrote:
On 02/02/2021 14:48, Marc Zyngier wrote:
Not sure. I also now notice an error for the SAS PCI driver on D06
when nr_cpus < 16, which means number of MSI vectors allocated < 32,
so looks the same problem. There we try to allocate 16 + max(nr
cpus, 16)
On 21-02-03 17:15:34, Christoph Hellwig wrote:
> On Tue, Feb 02, 2021 at 10:24:18AM -0800, Ben Widawsky wrote:
> > > > + /* Cap 4000h - CXL_CAP_CAP_ID_MEMDEV */
> > > > + struct {
> > > > + void __iomem *regs;
> > > > + } mem;
> > >
> > > This style looks massively
Hi!
> > > If I would not have the default-intensity I would actually see nothing,
> > > since the intensity (which goes from 0-255) of each led is initialized
> > > with 0.
> > >
> > > I hope I could clarify this a little more?
> >
> > Yes, sounds reasonable. Could we get default intensity
The number of deferred objects might get windup to an absurd number, and it
results in clamp of slab objects. It is undesirable for sustaining workingset.
So shrink deferred objects proportional to priority and cap nr_deferred to twice
of cache items.
The idea is borrowed fron Dave Chinner's
On Wed, 3 Feb 2021 17:35:55 +0100
Pavel Machek wrote:
> On Wed 2021-02-03 15:39:59, Sven Schuchmann wrote:
> > Hello Pavel,
> >
> > > > In order to use a multicolor-led together with a trigger
> > > > from DT the led needs to have an intensity set to see something.
> > > > The trigger changes
Now shrinker's nr_deferred is per memcg for memcg aware shrinkers, add to
parent's
corresponding nr_deferred when memcg offline.
Acked-by: Vlastimil Babka
Signed-off-by: Yang Shi
---
include/linux/memcontrol.h | 1 +
mm/memcontrol.c| 1 +
mm/vmscan.c| 24
Now nr_deferred is available on per memcg level for memcg aware shrinkers, so
don't need
allocate shrinker->nr_deferred for such shrinkers anymore.
The prealloc_memcg_shrinker() would return -ENOSYS if !CONFIG_MEMCG or memcg is
disabled
by kernel command line, then shrinker's
Use per memcg's nr_deferred for memcg aware shrinkers. The shrinker's
nr_deferred
will be used in the following cases:
1. Non memcg aware shrinkers
2. !CONFIG_MEMCG
3. memcg is disabled by boot parameter
Signed-off-by: Yang Shi
---
mm/vmscan.c | 94
Currently the number of deferred objects are per shrinker, but some slabs, for
example,
vfs inode/dentry cache are per memcg, this would result in poor isolation among
memcgs.
The deferred objects typically are generated by __GFP_NOFS allocations, one
memcg with
excessive __GFP_NOFS
Currently registered shrinker is indicated by non-NULL shrinker->nr_deferred.
This approach is fine with nr_deferred at the shrinker level, but the following
patches will move MEMCG_AWARE shrinkers' nr_deferred to memcg level, so their
shrinker->nr_deferred would always be NULL. This would
The shrinker map management is not purely memcg specific, it is at the
intersection
between memory cgroup and shrinkers. It's allocation and assignment of a
structure,
and the only memcg bit is the map is being stored in a memcg structure. So
move the
shrinker_maps handling code into vmscan.c
The following patch is going to add nr_deferred into shrinker_map, the change
will
make shrinker_map not only include map anymore, so rename it to
"memcg_shrinker_info".
And this should make the patch adding nr_deferred cleaner and readable and make
review easier. Also remove the "memcg_"
Both memcg_shrinker_map_size and shrinker_nr_max is maintained, but actually the
map size can be calculated via shrinker_nr_max, so it seems unnecessary to keep
both.
Remove memcg_shrinker_map_size since shrinker_nr_max is also used by iterating
the
bit map.
Signed-off-by: Yang Shi
---
Since memcg_shrinker_map_size just can be changed under holding shrinker_rwsem
exclusively, the read side can be protected by holding read lock, so it sounds
superfluous to have a dedicated mutex.
Kirill Tkhai suggested use write lock since:
* We want the assignment to shrinker_maps is visible
Changelog
v5 --> v6:
* Rebased on top of
https://lore.kernel.org/linux-mm/1611216029-34397-1-git-send-email-abaci-bug...@linux.alibaba.com/
per Kirill.
* Don't register shrinker idr with NULL and remove idr_replace() per
Vlastimil.
* Move nr_deferred before map to guarantee
The tracepoint's nid should show what node the shrink happens on, the start
tracepoint
uses nid from shrinkctl, but the nid might be set to 0 before end tracepoint if
the
shrinker is not NUMA aware, so the traceing log may show the shrink happens on
one
node but end up on the other node. It
Hi Fabio,
Fabio Estevam wrote on Wed, 3 Feb 2021 14:10:15
-0300:
> Hi Miquel,
>
> On Wed, Feb 3, 2021 at 2:06 PM Miquel Raynal
> wrote:
> >
> > Commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's
> > max speed")
> > rationaly introduced a new condition on which the
On 21-02-02 15:57:03, Dan Williams wrote:
> On Tue, Feb 2, 2021 at 3:51 PM Ben Widawsky wrote:
> >
> > On 21-02-01 13:28:48, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Jan 29, 2021 at 04:24:37PM -0800, Ben Widawsky wrote:
> > > > The Get Log command returns the actual log entries that are
On Tue, Feb 02, 2021 at 10:24:18AM -0800, Ben Widawsky wrote:
> > > + /* Cap 4000h - CXL_CAP_CAP_ID_MEMDEV */
> > > + struct {
> > > + void __iomem *regs;
> > > + } mem;
> >
> > This style looks massively obsfucated. For one the comments look like
> > absolute gibberish, but also what is
On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
>
> On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
> > >
> > > >>Uh, that doesn't work. If you want infinite compute queues you need the
> > > amdkfd model with preempt-ctx
On Tue, Feb 02, 2021 at 10:31:51AM -0800, Ben Widawsky wrote:
> > > + if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
> > > + rc = 0;
> > > + cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> > > + if (!cxlm)
> > > + rc =
On 2/3/21 6:43 AM, Mihai Carabas wrote:
> diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
> new file mode 100644
> index ..12bb017
> --- /dev/null
> +++ b/drivers/misc/pvpanic/Kconfig
> @@ -0,0 +1,14 @@
> +config PVPANIC
> + bool "pvpanic device support"
> +
Hello Pavel,
>
> Yes, sounds reasonable. Could we get default intensity of 100% on all
> channels if nothing else is specified?
>
> Or maybe simply "if intensity is not specified, start with 100%, and
> use explicit =0 if other color is expected".
>
Mh, if someone is already using the led
701 - 800 of 1611 matches
Mail list logo
