Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Acked-by: David Hildenbrand
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 8
include/uapi
On 22.04.24 09:42, zhenwei pi wrote:
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 8
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 8
include/uapi/linux/virtio_balloon.h | 6
-everything
patch link:
https://lore.kernel.org/r/20240418062602.1291391-3-pizhenwei%40bytedance.com
patch subject: [PATCH 2/3] virtio_balloon: introduce memory allocation stall
counter
config: i386-randconfig-141-20240421
(https://download.01.org/0day-ci/archive/20240421/202404211106.b9pwufqk
On 18.04.24 08:26, zhenwei pi wrote:
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 20
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 20 +++-
include/uapi/linux
On 15.04.24 10:41, zhenwei pi wrote:
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 19
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 19 ++-
include/uapi/linux
On 20/04/21 07:45, Shivank Garg wrote:
Hi,
I'm learning about qemu KVM, looking into code and experimenting on
it. I have the following doubts regarding it, I would be grateful if
you help me to get some idea on them.
1. I observe that KVM allocates memory to guests when it needs it but
doesn't
Hi,
I'm learning about qemu KVM, looking into code and experimenting on
it. I have the following doubts regarding it, I would be grateful if
you help me to get some idea on them.
1. I observe that KVM allocates memory to guests when it needs it but
doesn't take it back (except for ballooning
On Mon 12-04-21 15:49:53, ultrac...@163.com wrote:
> From: Chen Xiaoguang
>
> Check memory cgroup limit before allocating real memory. This may
> improve performance especially in slow path when memory allocation
> exceeds cgroup limitation.
I would be really curious about any
, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/ultrachin-163-com/mm-optimize-memory-allocation/20210412-155259
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/ultrachin-163-com/mm-optimize-memory-allocation/20210412-155259
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
From: Bruce Allan
commit 59df14f9cc2326bd6432d60eca0df8201d9d3d4b upstream.
Fix the order of number of array members and member size parameters in a
*calloc() call.
Fixes: b3c3890489f6 ("ice: avoid unnecessary single-member variable-length
structs")
Signed-off-by: Bruce Allan
Tested-by: Tony
From: Bruce Allan
commit 59df14f9cc2326bd6432d60eca0df8201d9d3d4b upstream.
Fix the order of number of array members and member size parameters in a
*calloc() call.
Fixes: b3c3890489f6 ("ice: avoid unnecessary single-member variable-length
structs")
Signed-off-by: Bruce Allan
Tested-by: Tony
From: Chen Xiaoguang
Check memory cgroup limit before allocating real memory. This may
improve performance especially in slow path when memory allocation
exceeds cgroup limitation.
Signed-off-by: Chen Xiaoguang
Signed-off-by: Chen He
---
include/linux/memcontrol.h | 30
id), GFP_KERNEL);
- if (!new_bus_id) {
- pr_err(PREFIX "Memory allocation error\n");
- result = -ENOMEM;
- goto err_detach;
- }
-
mutex_lock(_device_lock);
- /*
-* Find suitable bus_id and instance number in acpi_bus_id_list
-
id), GFP_KERNEL);
- if (!new_bus_id) {
- pr_err(PREFIX "Memory allocation error\n");
- result = -ENOMEM;
- goto err_detach;
- }
-
mutex_lock(_device_lock);
- /*
-* Find suitable bus_id and instance number in acpi_bus_id_list
-
id), GFP_KERNEL);
- if (!new_bus_id) {
- pr_err(PREFIX "Memory allocation error\n");
- result = -ENOMEM;
- goto err_detach;
- }
-
mutex_lock(_device_lock);
- /*
-* Find suitable bus_id and instance number in acpi_bus_id_list
-
id), GFP_KERNEL);
- if (!new_bus_id) {
- pr_err(PREFIX "Memory allocation error\n");
- result = -ENOMEM;
- goto err_detach;
- }
-
mutex_lock(_device_lock);
- /*
-* Find suitable bus_id and instance number in acpi_bus_id_list
-
id), GFP_KERNEL);
- if (!new_bus_id) {
- pr_err(PREFIX "Memory allocation error\n");
- result = -ENOMEM;
- goto err_detach;
- }
-
mutex_lock(_device_lock);
- /*
-* Find suitable bus_id and instance number in acpi_bus_id_list
-
id), GFP_KERNEL);
- if (!new_bus_id) {
- pr_err(PREFIX "Memory allocation error\n");
- result = -ENOMEM;
- goto err_detach;
- }
-
mutex_lock(_device_lock);
- /*
-* Find suitable bus_id and instance number in acpi_bus_id_list
-
When SEV-SNP is globally enabled on a system, the VMRUN instruction
performs additional security checks on AVIC backing, VMSA, and VMCB page.
On a successful VMRUN, these pages are marked "in-use" by the
hardware in the RMP entry, and any attempt to modify the RMP entry for
these pages will result
On 3/24/21 7:38 AM, zhouchuangao wrote:
Allocate memory for struct fuse_conn may fail, we should not jump to
out_err to kfree(fc).
Why not? If fc's allocation fails then it is NULL and calling kfree() on
a NULL pointer is a noop[1].
Connor
[1]
Allocate memory for struct fuse_conn may fail, we should not jump to
out_err to kfree(fc).
Signed-off-by: zhouchuangao
---
fs/fuse/virtio_fs.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 4ee6f73..1f333c6 100644
---
In preparation for enabling the creation of page-tables at EL2, factor
all memory allocation out of the page-table code, hence making it
re-usable with any compatible memory allocator.
No functional changes intended.
Acked-by: Will Deacon
Signed-off-by: Quentin Perret
---
arch/arm64/include
On 2021/3/16 11:15, Huang Jianan via Linux-erofs wrote:
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
On Tue, Mar 16, 2021 at 09:11:02AM +0800, Chao Yu wrote:
> On 2021/3/5 17:58, Huang Jianan via Linux-erofs wrote:
> > Currently, err would be treated as io error. Therefore, it'd be
> > better to ensure memory allocation during rolling decompression
> > to avoid such io error.
On 2021/3/5 17:58, Huang Jianan via Linux-erofs wrote:
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case.
Signed
In preparation for enabling the creation of page-tables at EL2, factor
all memory allocation out of the page-table code, hence making it
re-usable with any compatible memory allocator.
No functional changes intended.
Acked-by: Will Deacon
Signed-off-by: Quentin Perret
---
arch/arm64/include
On Fri, Mar 05, 2021 at 05:58:39PM +0800, Huang Jianan via Linux-erofs wrote:
> Currently, err would be treated as io error. Therefore, it'd be
> better to ensure memory allocation during rolling decompression
> to avoid such io error.
>
> In the long term, we might consider
On Wed, Mar 10, 2021 at 05:57:23PM +, Quentin Perret wrote:
> In preparation for enabling the creation of page-tables at EL2, factor
> all memory allocation out of the page-table code, hence making it
> re-usable with any compatible memory allocator.
>
> No functional c
In preparation for enabling the creation of page-tables at EL2, factor
all memory allocation out of the page-table code, hence making it
re-usable with any compatible memory allocator.
No functional changes intended.
Signed-off-by: Quentin Perret
---
arch/arm64/include/asm/kvm_pgtable.h | 41
Hi Peter,
On 09/03/21 11:09 am, Sanket Parmar wrote:
> Hi Peter,
>
>> On 21-03-05 17:01:11, Sanket Parmar wrote:
>>> Allocation of DMA coherent memory in atomic context using
>>> dma_alloc_coherent() might fail on some platform. To fix it,
>>> Replaced dma_alloc_coherent() with dma_pool API to
Hi Peter,
> On 21-03-05 17:01:11, Sanket Parmar wrote:
> > Allocation of DMA coherent memory in atomic context using
> > dma_alloc_coherent() might fail on some platform. To fix it,
> > Replaced dma_alloc_coherent() with dma_pool API to allocate a
> > smaller chunk of DMA coherent memory for TRB
On 21-03-05 17:01:11, Sanket Parmar wrote:
> Allocation of DMA coherent memory in atomic context using
> dma_alloc_coherent() might fail on some platform. To fix it,
> Replaced dma_alloc_coherent() with dma_pool API to allocate a
> smaller chunk of DMA coherent memory for TRB rings.
>
> Also in
Allocation of DMA coherent memory in atomic context using
dma_alloc_coherent() might fail on some platform. To fix it,
Replaced dma_alloc_coherent() with dma_pool API to allocate a
smaller chunk of DMA coherent memory for TRB rings.
Also in cdns3_prepare_aligned_request_buf(), replaced
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
On Fri, Mar 05, 2021 at 02:22:18PM +0800, Huang Jianan via Linux-erofs wrote:
> It should be better to ensure memory allocation during rolling
> decompression to avoid io error.
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during r
It should be better to ensure memory allocation during rolling
decompression to avoid io error.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/decompressor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/erofs/decompressor.c b/fs/erofs
On Tue, Mar 02, 2021 at 02:59:36PM +, Quentin Perret wrote:
> In preparation for enabling the creation of page-tables at EL2, factor
> all memory allocation out of the page-table code, hence making it
> re-usable with any compatible memory allocator.
>
> No functional c
When allocating the cpuc->lbr_xsave memory in the guest Arch LBR driver,
we may get a stacktrace due to relatively slow execution like below:
[ 54.283563] BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:196
[ 54.285218] in_atomic(): 1, irqs_disabled(): 1,
In preparation for enabling the creation of page-tables at EL2, factor
all memory allocation out of the page-table code, hence making it
re-usable with any compatible memory allocator.
No functional changes intended.
Signed-off-by: Quentin Perret
---
arch/arm64/include/asm/kvm_pgtable.h | 41
On Wed, Feb 24, 2021 at 05:02:09PM -0800, Ivan Babrou wrote:
> Hello,
>
> We started seeing allocation failures on procfs reads after
> commit 4bd6a7353ee1 "sysctl: Convert to iter interfaces".
Hello,
We started seeing allocation failures on procfs reads after
commit 4bd6a7353ee1 "sysctl: Convert to iter interfaces".
I haven't done a full bisect, but the decoded stacks point
squarely at the following piece of code which was introduced:
kbuf = kzalloc(count + 1, GFP_KERNEL);
On Mon, 2021-02-22 at 01:41 -0800, Andrew Pinski wrote:
> On Mon, Feb 22, 2021 at 1:37 AM Michael J. Baars
> wrote:
> > On Mon, 2021-02-22 at 01:29 -0800, Andrew Pinski wrote:
> > > On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
> > > wrote:
> > > > Hi,
> > > >
> > > > I just wrote this
> > > I just wrote this little program to demonstrate a possible flaw in both
> > > malloc and calloc.
> > >
> > > If I allocate a the simplest memory region from main(), one out of three
> > > optimization flags fail.
> > > If I allocate the same region from a function, three out of three
> >
On Mon, 2021-02-22 at 01:29 -0800, Andrew Pinski wrote:
> On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
> wrote:
> > Hi,
> >
> > I just wrote this little program to demonstrate a possible flaw in both
> > malloc and calloc.
> >
> > If I allocate a the simplest memory region from main(), one
On Mon, 2021-02-22 at 01:41 -0800, Andrew Pinski wrote:
> On Mon, Feb 22, 2021 at 1:37 AM Michael J. Baars
> wrote:
> > On Mon, 2021-02-22 at 01:29 -0800, Andrew Pinski wrote:
> > > On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
> > > wrote:
> > > > Hi,
> > > >
> > > > I just wrote this
On Mon, Feb 22, 2021 at 1:37 AM Michael J. Baars
wrote:
>
> On Mon, 2021-02-22 at 01:29 -0800, Andrew Pinski wrote:
> > On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
> > wrote:
> > > Hi,
> > >
> > > I just wrote this little program to demonstrate a possible flaw in both
> > > malloc and
Hi,
I just wrote this little program to demonstrate a possible flaw in both malloc
and calloc.
If I allocate a the simplest memory region from main(), one out of three
optimization flags fail.
If I allocate the same region from a function, three out of three optimization
flags fail.
Does
On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
wrote:
>
> Hi,
>
> I just wrote this little program to demonstrate a possible flaw in both
> malloc and calloc.
>
> If I allocate a the simplest memory region from main(), one out of three
> optimization flags fail.
> If I allocate the same
On Mon, Feb 01, 2021 at 06:32:52PM +, Quentin Perret wrote:
> On Monday 01 Feb 2021 at 18:16:08 (+), Will Deacon wrote:
> > On Fri, Jan 08, 2021 at 12:15:04PM +, Quentin Perret wrote:
> > > +static struct kvm_pgtable_mm_ops kvm_s2_mm_ops = {
> > > + .zalloc_page=
On Monday 01 Feb 2021 at 18:16:08 (+), Will Deacon wrote:
> On Fri, Jan 08, 2021 at 12:15:04PM +, Quentin Perret wrote:
> > In preparation for enabling the creation of page-tables at EL2, factor
> > all memory allocation out of the page-table code, hence making it
> &g
On Fri, Jan 08, 2021 at 12:15:04PM +, Quentin Perret wrote:
> In preparation for enabling the creation of page-tables at EL2, factor
> all memory allocation out of the page-table code, hence making it
> re-usable with any compatible memory allocator.
>
> No functional c
On Wed, 27 Jan 2021 18:08:34 +1100
Alexey Kardashevskiy wrote:
>
> I am running syzkaller and the kernel keeps crashing in
> __traceiter_##_name. This patch makes these crashes happen lot less
I have another solution to the above issue. But I'm now concerned with what
you write below.
>
On 18/11/2020 23:46, Steven Rostedt wrote:
On Tue, 17 Nov 2020 20:54:24 -0800
Alexei Starovoitov wrote:
extern int
@@ -310,7 +312,12 @@ static inline struct tracepoint
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
do {\
ruct acpi_device_bus_id *acpi_device_bus_id;
> > int result;
> > - struct acpi_device_bus_id *acpi_device_bus_id, *new_bus_id;
> > - int found = 0;
> >
> > if (device->handle) {
> > acpi_status status;
> > @@ -652,
Hi,
On 1/18/21 4:32 PM, Andy Shevchenko wrote:
> On Mon, Jan 18, 2021 at 04:16:16PM +0100, Rafael J. Wysocki wrote:
>> On Sat, Jan 16, 2021 at 1:37 PM Hans de Goede wrote:
>>> On 1/14/21 7:46 PM, Rafael J. Wysocki wrote:
>
> ...
>
>>> When I have cases like this, where 2 mallocs are necessary
On Mon, Jan 18, 2021 at 04:16:16PM +0100, Rafael J. Wysocki wrote:
> On Sat, Jan 16, 2021 at 1:37 PM Hans de Goede wrote:
> > On 1/14/21 7:46 PM, Rafael J. Wysocki wrote:
...
> > When I have cases like this, where 2 mallocs are necessary I typically do
> > it like this:
> >
> > const
acpi_device_hid(device))) {
>>> - acpi_device_bus_id->instance_no++;
>>> - found = 1;
>>> - kfree(new_bus_id);
>>> - break;
>>> +
>>> + acpi_device_bus_id =
>>> acpi_device_bus_id_match(
dd(struct acpi_device *
> INIT_LIST_HEAD(>del_list);
> mutex_init(>physical_node_lock);
>
> - new_bus_id = kzalloc(sizeof(struct acpi_device_bus_id), GFP_KERNEL);
> - if (!new_bus_id) {
> - pr_err(PREFIX "Memory allocation error\n")
26 @@ int acpi_device_add(struct acpi_device *
INIT_LIST_HEAD(>del_list);
mutex_init(>physical_node_lock);
- new_bus_id = kzalloc(sizeof(struct acpi_device_bus_id), GFP_KERNEL);
- if (!new_bus_id) {
- pr_err(PREFIX "Memory allocation error\n"
In preparation for enabling the creation of page-tables at EL2, factor
all memory allocation out of the page-table code, hence making it
re-usable with any compatible memory allocator.
No functional changes intended.
Signed-off-by: Quentin Perret
---
arch/arm64/include/asm/kvm_pgtable.h | 32
From: Colin Ian King
Currently when an alloc_page fails the error return is not set in
variable err and a garbage initialized value is returned. Fix this
by setting err to -ENOMEM before taking the error return path.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: a1f26739ccdc
Committer: Paul E. McKenney
CommitterDate: Thu, 19 Nov 2020 19:37:17 -08:00
srcu: Take early exit on memory-allocation failure
It turns out that init_srcu_struct() can be invoked from usermode tasks,
and that fatal signals received by these tasks can cause memory-allocation
failures
On Tue, Nov 17, 2020 at 09:01:45AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Changelog:
> v5:
> * Reorder patches to postpone changes in rdma_restrack_add to be in next
> series.
> v4:
> https://lore.kernel.org/linux-rdma/20201104144008.3808124-1-l...@kernel.org/
> * Rebased
On Wed, Nov 18, 2020 at 09:34:05AM -0500, Steven Rostedt 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 then the
arm64 Juno platform with 6 CPUs:
> - (0) 0, 1, 2, 3, 4, 5 - NONE coordination
> - (1) (0, 1, 2, 3) in PSD1, (4, 5) in PSD2 - ANY coordination
>
> memory allocation comparison shows:
>
> Before patch: psd_data and cppc_cpudata structures are allocated for each
> C
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 then the list of functions for the
tracepoint is switched over to the new array.
On Tue, 17 Nov 2020 20:54:24 -0800
Alexei Starovoitov wrote:
> > extern int
> > @@ -310,7 +312,12 @@ static inline struct tracepoint
> > *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> > do {\
> > it_func
On Tue, Nov 17, 2020 at 02:02:30PM +, Christoph Hellwig wrote:
> On Tue, Nov 17, 2020 at 03:00:32PM +0100, Arnaud POULIQUEN wrote:
> > The dma_declare_coherent_memory allows to associate vdev0buffer memory
> > region
> > to the remoteproc virtio device (vdev parent). This region is used to
>
On Tue, Nov 17, 2020 at 6:18 PM Steven Rostedt 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 then the list of
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 then the list of functions for the
tracepoint is switched over to the new array.
On Tue, 17 Nov 2020 18:08:19 -0500 (EST)
Mathieu Desnoyers wrote:
> Because of this end-of-loop condition ^
> which is also testing for a NULL func. So if we reach a stub, we end up
> stopping
> iteration and not firing the following tracepoint probes.
Ah right. OK, since it's looking like
- On Nov 17, 2020, at 5:19 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 13:33:42 -0800
> Kees Cook wrote:
>
>> As I think got discussed in the thread, what you had here wouldn't work
>> in a CFI build if the function prototype of the call site and the
>> function don't
- On Nov 17, 2020, at 5:16 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 16:22:23 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> If we don't call the stub, then there is no point in having the stub at
>> all, and we should just compare to a constant value, e.g. 0x1UL. As far
>>
On Tue, 17 Nov 2020 13:33:42 -0800
Kees Cook wrote:
> As I think got discussed in the thread, what you had here wouldn't work
> in a CFI build if the function prototype of the call site and the
> function don't match. (Though I can't tell if .func() is ever called?)
>
> i.e. .func's prototype
On Tue, 17 Nov 2020 16:22:23 -0500 (EST)
Mathieu Desnoyers wrote:
> If we don't call the stub, then there is no point in having the stub at
> all, and we should just compare to a constant value, e.g. 0x1UL. As far
> as I can recall, comparing with a small immediate constant is more efficient
>
On Mon, Nov 16, 2020 at 05:51:07PM -0500, Steven Rostedt wrote:
> [ Kees, I added you because you tend to know about these things.
> Is it OK to assign a void func(void) that doesn't do anything and returns
> nothing to a function pointer that could be call with parameters? We need
> to add
- On Nov 17, 2020, at 3:58 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 15:34:51 -0500
> Steven Rostedt wrote:
[...]
> If it comes down to not trusting calling a stub, I'll still keep the stub
> logic in, and just add the following:
If we don't call the stub, then there is
- On Nov 17, 2020, at 3:34 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 14:47:20 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> There seems to be more effect on the data size: adding the "stub_func" field
>> in struct tracepoint adds 8320 bytes of data to my vmlinux. But
On Tue, 17 Nov 2020 15:34:51 -0500
Steven Rostedt wrote:
> On Tue, 17 Nov 2020 14:47:20 -0500 (EST)
> Mathieu Desnoyers wrote:
>
> > There seems to be more effect on the data size: adding the "stub_func" field
> > in struct tracepoint adds 8320 bytes of data to my vmlinux. But considering
> >
On Tue, 17 Nov 2020 14:47:20 -0500 (EST)
Mathieu Desnoyers wrote:
> There seems to be more effect on the data size: adding the "stub_func" field
> in struct tracepoint adds 8320 bytes of data to my vmlinux. But considering
> the layout of struct tracepoint:
>
> struct tracepoint {
>
- On Nov 17, 2020, at 2:21 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 14:15:10 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>
>> diff --git a/include/linux/tracepoint-defs.h
>> b/include/linux/tracepoint-defs.h
>> index e7c2276be33e..e0351bb0b140 100644
>> ---
On Tue, 17 Nov 2020 14:15:10 -0500 (EST)
Mathieu Desnoyers wrote:
> diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
> index e7c2276be33e..e0351bb0b140 100644
> --- a/include/linux/tracepoint-defs.h
> +++ b/include/linux/tracepoint-defs.h
> @@ -38,6 +38,7 @@ struct
- On Nov 16, 2020, at 5:51 PM, rostedt rost...@goodmis.org wrote:
> [ Kees, I added you because you tend to know about these things.
> Is it OK to assign a void func(void) that doesn't do anything and returns
> nothing to a function pointer that could be call with parameters? We need
> to
coordination types, with the greatest
savings obtained for HW and NONE coordination, when the number of CPUs
is large.
For example, on a arm64 Juno platform with 6 CPUs:
- (0) 0, 1, 2, 3, 4, 5 - NONE coordination
- (1) (0, 1, 2, 3) in PSD1, (4, 5) in PSD2 - ANY coordination
memory allocation
In preparation for enabling the creation of page-tables at EL2, factor
all memory allocation out of the page-table code, hence making it
re-usable with any compatible memory allocator.
No functional changes intended.
Signed-off-by: Quentin Perret
---
arch/arm64/include/asm/kvm_pgtable.h | 32
On 11/16/20 5:39 PM, Christoph Hellwig wrote:
> Btw, I also still don't understand why remoteproc is using
> dma_declare_coherent_memory to start with. The virtio code has exactly
> one call to dma_alloc_coherent vring_alloc_queue, a function that
> already switches between two different
On Tue, Nov 17, 2020 at 03:00:32PM +0100, Arnaud POULIQUEN wrote:
> The dma_declare_coherent_memory allows to associate vdev0buffer memory region
> to the remoteproc virtio device (vdev parent). This region is used to
> allocated
> the rpmsg buffers.
> The memory for the rpmsg buffer is allocated
From: Alexander Lobakin
commit 9d516aa82b7d4fbe7f6303348697960ba03a530b upstream.
Since commit 086d08725d34 ("remoteproc: create vdev subdevice with
specific dma memory pool"), every remoteproc has a DMA subdevice
("remoteprocX#vdevYbuffer") for each virtio device, which inherits
DMA
From: Alexander Lobakin
commit 9d516aa82b7d4fbe7f6303348697960ba03a530b upstream.
Since commit 086d08725d34 ("remoteproc: create vdev subdevice with
specific dma memory pool"), every remoteproc has a DMA subdevice
("remoteprocX#vdevYbuffer") for each virtio device, which inherits
DMA
From: Leon Romanovsky
Changelog:
v5:
* Reorder patches to postpone changes in rdma_restrack_add to be in next
series.
v4: https://lore.kernel.org/linux-rdma/20201104144008.3808124-1-l...@kernel.org/
* Rebased on latest for-upstream, all that time the patches were in
our regression and didn't
On Mon, 16 Nov 2020 17:51:07 -0500
Steven Rostedt wrote:
> [ Kees, I added you because you tend to know about these things.
> Is it OK to assign a void func(void) that doesn't do anything and returns
> nothing to a function pointer that could be call with parameters? We need
> to add stubs
[ Kees, I added you because you tend to know about these things.
Is it OK to assign a void func(void) that doesn't do anything and returns
nothing to a function pointer that could be call with parameters? We need
to add stubs for tracepoints when we fail to allocate a new array on
From: Christoph Hellwig
Date: Mon, 16 Nov 2020 16:27:44 +
> On Mon, Nov 16, 2020 at 04:51:49AM -0500, Michael S. Tsirkin wrote:
>> On Mon, Nov 16, 2020 at 09:19:50AM +, Christoph Hellwig wrote:
>>> I just noticed this showing up in Linus' tree and I'm not happy.
>>>
>>> This whole model
Btw, I also still don't understand why remoteproc is using
dma_declare_coherent_memory to start with. The virtio code has exactly
one call to dma_alloc_coherent vring_alloc_queue, a function that
already switches between two different allocators. Why can't we just
add a third allocator
1 - 100 of 4626 matches
Mail list logo
