This actually seems to break the compilation for me in for-next:
hch@carbon:~/work/linux$ make ARCH=riscv
CALLscripts/checksyscalls.sh
:1335:2: warning: #warning syscall rseq not implemented [-Wcpp]
CHK include/generated/compile.h
CC arch/riscv/kernel/syscall_table.o
This actually seems to break the compilation for me in for-next:
hch@carbon:~/work/linux$ make ARCH=riscv
CALLscripts/checksyscalls.sh
:1335:2: warning: #warning syscall rseq not implemented [-Wcpp]
CHK include/generated/compile.h
CC arch/riscv/kernel/syscall_table.o
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
>
> This patch refactors the code that initializes and sets up the
> crypto configuration for a guest. The following changes are
> implemented via this patch:
>
> 1. Prior to the introduction of AP device virtualization, it
>was
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
>
> This patch refactors the code that initializes and sets up the
> crypto configuration for a guest. The following changes are
> implemented via this patch:
>
> 1. Prior to the introduction of AP device virtualization, it
>was
Hi Jacek,
On 9 August 2018 at 05:28, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 08/08/2018 08:01 AM, Baolin Wang wrote:
>> Hi Jacek,
>>
>> On 8 August 2018 at 05:54, Jacek Anaszewski
>> wrote:
>>> Hi Baolin,
>>>
>>> Thank you for addressing the review remarks.
>>> Since the patch set is
Hi Jacek,
On 9 August 2018 at 05:28, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 08/08/2018 08:01 AM, Baolin Wang wrote:
>> Hi Jacek,
>>
>> On 8 August 2018 at 05:54, Jacek Anaszewski
>> wrote:
>>> Hi Baolin,
>>>
>>> Thank you for addressing the review remarks.
>>> Since the patch set is
The idle loop stops tick by respecting the decision from cpuidle
framework, if the condition 'need_resched()' is false without any task
scheduling, the CPU keeps running in the loop in do_idle() and it has no
chance call tick_nohz_idle_exit() to enable the tick. This results in
the idle loop
Hi Linus:
This push fixes a performance regression in arm64 NEON crypto as
well as a crash in x86 aegis/morus on unsupported CPUs.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Ard Biesheuvel (1):
crypto: arm64 - revert NEON yield for fast
The idle loop stops tick by respecting the decision from cpuidle
framework, if the condition 'need_resched()' is false without any task
scheduling, the CPU keeps running in the loop in do_idle() and it has no
chance call tick_nohz_idle_exit() to enable the tick. This results in
the idle loop
Hi Linus:
This push fixes a performance regression in arm64 NEON crypto as
well as a crash in x86 aegis/morus on unsupported CPUs.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Ard Biesheuvel (1):
crypto: arm64 - revert NEON yield for fast
On 07.08.2018 14:51, David Hildenbrand wrote:
> When we change the crycb (or execution controls), we also have to make sure
> that the vSIE shadow datastructures properly consider the changed
> values before rerunning the vSIE. We can achieve that by simply using a
> VCPU request now.
>
> This
On 07.08.2018 14:51, David Hildenbrand wrote:
> When we change the crycb (or execution controls), we also have to make sure
> that the vSIE shadow datastructures properly consider the changed
> values before rerunning the vSIE. We can achieve that by simply using a
> VCPU request now.
>
> This
On 07.08.2018 14:51, David Hildenbrand wrote:
> VCPU requests and VCPU blocking right now don't take care of the vSIE
> (as it was not necessary until now). But we want to have VCPU requests
> that will also be handled before running the vSIE again.
>
> So let's simulate a SIE entry when entering
On 07.08.2018 14:51, David Hildenbrand wrote:
> VCPU requests and VCPU blocking right now don't take care of the vSIE
> (as it was not necessary until now). But we want to have VCPU requests
> that will also be handled before running the vSIE again.
>
> So let's simulate a SIE entry when entering
The host-progs has been supported as an alias of hostprogs-y at least
since the beginning of Git era, with the clear prompt:
Usage of host-progs is deprecated. Please replace with hostprogs-y!
Enough time for the migration has passed.
Signed-off-by: Masahiro Yamada
---
The host-progs has been supported as an alias of hostprogs-y at least
since the beginning of Git era, with the clear prompt:
Usage of host-progs is deprecated. Please replace with hostprogs-y!
Enough time for the migration has passed.
Signed-off-by: Masahiro Yamada
---
2018-08-06 23:37 GMT+09:00 Vasily Gorbik :
> With kbuild there is no easy way to re-compile source files from another
> directory, which is required for the decompressor on some platforms
> (files like lib/ctype.c, lib/cmdline.c, etc). Writing custom build
> rules for those files is not feasible
2018-08-06 23:37 GMT+09:00 Vasily Gorbik :
> With kbuild there is no easy way to re-compile source files from another
> directory, which is required for the decompressor on some platforms
> (files like lib/ctype.c, lib/cmdline.c, etc). Writing custom build
> rules for those files is not feasible
I am trying to understand how agetty process is called when
ALT+CTRL+F2/ALT+CTRL+F3/ keys are pressed in CentOS or in any
other linux distro.
What I know so far
- systemd runs agetty.service with next tty[N] number
- agetty then run login process and then other process continues.
What I
I am trying to understand how agetty process is called when
ALT+CTRL+F2/ALT+CTRL+F3/ keys are pressed in CentOS or in any
other linux distro.
What I know so far
- systemd runs agetty.service with next tty[N] number
- agetty then run login process and then other process continues.
What I
2018-08-06 22:38 GMT+09:00 Vasily Gorbik :
> Add "Map" kbuild option, so that "make Map=1" would save vmlinux linker
> map into vmlinux.map, which is quite useful during making kernel changes
> related to how the kernel is composed.
>
> KBUILD_SAVE_LINK_MAP flag is exported and architectures
>
2018-08-06 22:38 GMT+09:00 Vasily Gorbik :
> Add "Map" kbuild option, so that "make Map=1" would save vmlinux linker
> map into vmlinux.map, which is quite useful during making kernel changes
> related to how the kernel is composed.
>
> KBUILD_SAVE_LINK_MAP flag is exported and architectures
>
Create auxiliary trace data log files when invoked with option
--itrace=d as in
[root@s35lp76 perf] ./perf report -i perf.data.aux1 --stdio --itrace=d
perf report creates several data files in the current directory
named aux.smp.## where ## is a 2 digit hex number with
leading zeros
Create auxiliary trace data log files when invoked with option
--itrace=d as in
[root@s35lp76 perf] ./perf report -i perf.data.aux1 --stdio --itrace=d
perf report creates several data files in the current directory
named aux.smp.## where ## is a 2 digit hex number with
leading zeros
Hi Krzysztof,
On 2018년 08월 08일 01:21, Krzysztof Kozlowski wrote:
> Replace GPL v2.0+ license statements with SPDX license identifiers.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/extcon/extcon-max14577.c | 24 +++-
> drivers/extcon/extcon-max77693.c | 22
Hi Krzysztof,
On 2018년 08월 08일 01:21, Krzysztof Kozlowski wrote:
> Replace GPL v2.0+ license statements with SPDX license identifiers.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/extcon/extcon-max14577.c | 24 +++-
> drivers/extcon/extcon-max77693.c | 22
On 08/08/2018 06:42 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Aug 08, 2018 at 01:14:51PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Aug 08, 2018 at 01:08:43PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> No need for __packed.
>>
>>> I'm removing that to avoid having this failling
On 08/08/2018 06:42 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Aug 08, 2018 at 01:14:51PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Aug 08, 2018 at 01:08:43PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> No need for __packed.
>>
>>> I'm removing that to avoid having this failling
v8 changes:
- Call delayed_uprobe_remove(uprobe, NULL) from put_uprobe() as well.
- Other minor optimizations.
v7: https://lkml.org/lkml/2018/7/31/20
Description:
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL,
v8 changes:
- Call delayed_uprobe_remove(uprobe, NULL) from put_uprobe() as well.
- Other minor optimizations.
v7: https://lkml.org/lkml/2018/7/31/20
Description:
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL,
Simplify uprobe_register() function body and let __uprobe_register()
handle everything. Also move dependency functions around to fix build
failures.
Signed-off-by: Ravi Bangoria
---
kernel/events/uprobes.c | 69 ++---
1 file changed, 36 insertions(+),
We assume to have only one reference counter for one uprobe.
Don't allow user to add multiple trace_uprobe entries having
same inode+offset but different reference counter.
Ex,
# echo "p:sdt_tick/loop2 /home/ravi/tick:0x6e4(0x10036)" > uprobe_events
# echo "p:sdt_tick/loop2_1
Add addition argument 'arch_uprobe' to uprobe_write_opcode().
We need this in later set of patches.
Signed-off-by: Ravi Bangoria
---
arch/arm/probes/uprobes/core.c | 2 +-
arch/mips/kernel/uprobes.c | 2 +-
include/linux/uprobes.h| 2 +-
kernel/events/uprobes.c| 9 +
With this, perf buildid-cache will save SDT markers with reference
counter in probe cache. Perf probe will be able to probe markers
having reference counter. Ex,
# readelf -n /tmp/tick | grep -A1 loop2
Name: loop2
... Semaphore: 0x10020036
# ./perf buildid-cache --add
Simplify uprobe_register() function body and let __uprobe_register()
handle everything. Also move dependency functions around to fix build
failures.
Signed-off-by: Ravi Bangoria
---
kernel/events/uprobes.c | 69 ++---
1 file changed, 36 insertions(+),
We assume to have only one reference counter for one uprobe.
Don't allow user to add multiple trace_uprobe entries having
same inode+offset but different reference counter.
Ex,
# echo "p:sdt_tick/loop2 /home/ravi/tick:0x6e4(0x10036)" > uprobe_events
# echo "p:sdt_tick/loop2_1
Add addition argument 'arch_uprobe' to uprobe_write_opcode().
We need this in later set of patches.
Signed-off-by: Ravi Bangoria
---
arch/arm/probes/uprobes/core.c | 2 +-
arch/mips/kernel/uprobes.c | 2 +-
include/linux/uprobes.h| 2 +-
kernel/events/uprobes.c| 9 +
With this, perf buildid-cache will save SDT markers with reference
counter in probe cache. Perf probe will be able to probe markers
having reference counter. Ex,
# readelf -n /tmp/tick | grep -A1 loop2
Name: loop2
... Semaphore: 0x10020036
# ./perf buildid-cache --add
We assume to have only one reference counter for one uprobe.
Don't allow user to register multiple uprobes having same
inode+offset but different reference counter.
Signed-off-by: Ravi Bangoria
---
kernel/events/uprobes.c | 9 +
1 file changed, 9 insertions(+)
diff --git
We assume to have only one reference counter for one uprobe.
Don't allow user to register multiple uprobes having same
inode+offset but different reference counter.
Signed-off-by: Ravi Bangoria
---
kernel/events/uprobes.c | 9 +
1 file changed, 9 insertions(+)
diff --git
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places
Dear Miklos,
Recently I've been testing FUSE and libfuse example passthrough_ll with
writeback cache on, and found out that the performance drops significantly
compared to that in local filesystem. As I can see from trace,
balance_dirty_pages is triggered very frequently even if there not
Dear Miklos,
Recently I've been testing FUSE and libfuse example passthrough_ll with
writeback cache on, and found out that the performance drops significantly
compared to that in local filesystem. As I can see from trace,
balance_dirty_pages is triggered very frequently even if there not
Hi Vinod,
(Comments from Eric Long)
On 9 August 2018 at 10:32, Vinod wrote:
> On 26-07-18, 16:00, Baolin Wang wrote:
>> From: Eric Long
>>
>> The Spreadtrum DMA can support the link-list transaction mode, which means
>> DMA controller can do transaction one by one automatically once we linked
Hi Vinod,
(Comments from Eric Long)
On 9 August 2018 at 10:32, Vinod wrote:
> On 26-07-18, 16:00, Baolin Wang wrote:
>> From: Eric Long
>>
>> The Spreadtrum DMA can support the link-list transaction mode, which means
>> DMA controller can do transaction one by one automatically once we linked
Hi Trent,
On 9 August 2018 at 03:08, Trent Piepho wrote:
> On Wed, 2018-08-08 at 11:19 +0800, Baolin Wang wrote:
>> On 8 August 2018 at 01:10, Trent Piepho wrote:
>> > On Tue, 2018-08-07 at 18:43 +0800, Baolin Wang wrote:
>> > >
>> > > +static u32 sprd_spi_transfer_max_timeout(struct sprd_spi
Hi Trent,
On 9 August 2018 at 03:08, Trent Piepho wrote:
> On Wed, 2018-08-08 at 11:19 +0800, Baolin Wang wrote:
>> On 8 August 2018 at 01:10, Trent Piepho wrote:
>> > On Tue, 2018-08-07 at 18:43 +0800, Baolin Wang wrote:
>> > >
>> > > +static u32 sprd_spi_transfer_max_timeout(struct sprd_spi
Hi Trent,
On 9 August 2018 at 02:57, Trent Piepho wrote:
> On Wed, 2018-08-08 at 11:54 +0100, Mark Brown wrote:
>> On Wed, Aug 08, 2018 at 06:35:28PM +0800, Baolin Wang wrote:
>> > On 8 August 2018 at 17:50, Mark Brown wrote:
>> > > Right, I don't think we added this yet (if we did I can't see
Hi Trent,
On 9 August 2018 at 02:57, Trent Piepho wrote:
> On Wed, 2018-08-08 at 11:54 +0100, Mark Brown wrote:
>> On Wed, Aug 08, 2018 at 06:35:28PM +0800, Baolin Wang wrote:
>> > On 8 August 2018 at 17:50, Mark Brown wrote:
>> > > Right, I don't think we added this yet (if we did I can't see
Track snd_soc_dapm_widget:id which is used as dapm
sequence index in dapm_down_seq/dapm_up_seq. It's
useful for checking dapm seq after tracking it.
Signed-off-by: Liu Changcheng
diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index bf17edc..7c4e8de 100644
---
Track snd_soc_dapm_widget:id which is used as dapm
sequence index in dapm_down_seq/dapm_up_seq. It's
useful for checking dapm seq after tracking it.
Signed-off-by: Liu Changcheng
diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index bf17edc..7c4e8de 100644
---
There's no need to do typecast since the defined type matches the output
fromat requirement.
Signed-off-by: Liu Changcheng
diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index 40c300f..bf17edc 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@
There's no need to do typecast since the defined type matches the output
fromat requirement.
Signed-off-by: Liu Changcheng
diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index 40c300f..bf17edc 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@
1. Some typecast are not needed
2. trace dapm type in snd_soc_dapm_widget class event
Liu Changcheng (2):
ASoC: trace: remove unnecessary typecast
ASoC: trace: track dapm type in snd_soc_dapm_widget
v1->v2
correct code style to meet kernel requirement.
include/trace/events/asoc.h | 21
Hi Pavel, Joey, Oliver
Please let me describe the original requirement and my
understanding about hibernation encryption here, thus
help us sync on the same thread:
On Wed, Aug 08, 2018 at 07:50:36PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > > User space doesn't need to involve. The EFI root key
1. Some typecast are not needed
2. trace dapm type in snd_soc_dapm_widget class event
Liu Changcheng (2):
ASoC: trace: remove unnecessary typecast
ASoC: trace: track dapm type in snd_soc_dapm_widget
v1->v2
correct code style to meet kernel requirement.
include/trace/events/asoc.h | 21
Hi Pavel, Joey, Oliver
Please let me describe the original requirement and my
understanding about hibernation encryption here, thus
help us sync on the same thread:
On Wed, Aug 08, 2018 at 07:50:36PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > > User space doesn't need to involve. The EFI root key
When hot-removing memory release_mem_region_adjustable() splits
iomem resources if they are not the exact size of the memory being
hot-deleted. Adding this memory back to the kernel adds a new
resource.
Eg a node has memory 0x0 - 0xf. Offlining and hot-removing
1GB from 0xf4000
When hot-removing memory release_mem_region_adjustable() splits
iomem resources if they are not the exact size of the memory being
hot-deleted. Adding this memory back to the kernel adds a new
resource.
Eg a node has memory 0x0 - 0xf. Offlining and hot-removing
1GB from 0xf4000
On Wed, Aug 08 2018, Frank Filz wrote:
>
> Now here's another question... How does this new logic play with Open
> File Description Locks? Should still be ok since there's a thread
> waiting on each of those.
At this level Posix locks and OFD locks are almost identical - just a
different owner.
On Wed, Aug 08 2018, Frank Filz wrote:
>
> Now here's another question... How does this new logic play with Open
> File Description Locks? Should still be ok since there's a thread
> waiting on each of those.
At this level Posix locks and OFD locks are almost identical - just a
different owner.
On 26-07-18, 10:36, Manivannan Sadhasivam wrote:
> Add Actions Semi Owl family S900 DMA driver.
Applied, thanks
--
~Vinod
On 26-07-18, 10:36, Manivannan Sadhasivam wrote:
> Add Actions Semi Owl family S900 DMA driver.
Applied, thanks
--
~Vinod
On 26-07-18, 10:36, Manivannan Sadhasivam wrote:
> Add devicetree binding for Actions Semi Owl SoCs DMA controller.
Applied, thanks
--
~Vinod
On 26-07-18, 10:36, Manivannan Sadhasivam wrote:
> Add devicetree binding for Actions Semi Owl SoCs DMA controller.
Applied, thanks
--
~Vinod
ASoC: trace: track dapm type in snd_soc_dapm_widget
Track snd_soc_dapm_widget:id which is used as dapm
sequence index in dapm_down_seq/dapm_up_seq. It's
useful for checking dapm seq after tracking it.
Signed-off-by: Liu Changcheng
diff --git a/include/trace/events/asoc.h
ASoC: trace: track dapm type in snd_soc_dapm_widget
Track snd_soc_dapm_widget:id which is used as dapm
sequence index in dapm_down_seq/dapm_up_seq. It's
useful for checking dapm seq after tracking it.
Signed-off-by: Liu Changcheng
diff --git a/include/trace/events/asoc.h
There's no need to do typecast since the defined type matches the output
fromat requirement.
Signed-off-by: Liu Changcheng
diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index 40c300f..bf17edc 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@
There's no need to do typecast since the defined type matches the output
fromat requirement.
Signed-off-by: Liu Changcheng
diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index 40c300f..bf17edc 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@
1. Some typecast are not needed.
2. trace dapm type in snd_soc_dapm_widget class event.
Liu Changcheng (2):
ASoC: trace: remove unnecessary typecast
ASoC: trace: track dapm type in snd_soc_dapm_widget
include/trace/events/asoc.h | 21 +++--
1 file changed, 11 insertions(+),
Hi Jerome
On 07/30/18 16:57, Jerome Brunet wrote:
> On Fri, 2018-07-27 at 09:45 -0700, Stephen Boyd wrote:
>> Quoting Stephen Boyd (2018-07-27 09:41:40)
>>> Quoting Yixun Lan (2018-07-27 07:52:23)
HI Stephen:
On 07/26/2018 11:20 PM, Stephen Boyd wrote:
> Quoting Yixun Lan
1. Some typecast are not needed.
2. trace dapm type in snd_soc_dapm_widget class event.
Liu Changcheng (2):
ASoC: trace: remove unnecessary typecast
ASoC: trace: track dapm type in snd_soc_dapm_widget
include/trace/events/asoc.h | 21 +++--
1 file changed, 11 insertions(+),
Hi Jerome
On 07/30/18 16:57, Jerome Brunet wrote:
> On Fri, 2018-07-27 at 09:45 -0700, Stephen Boyd wrote:
>> Quoting Stephen Boyd (2018-07-27 09:41:40)
>>> Quoting Yixun Lan (2018-07-27 07:52:23)
HI Stephen:
On 07/26/2018 11:20 PM, Stephen Boyd wrote:
> Quoting Yixun Lan
On 03-08-18, 10:47, Peter Ujfalusi wrote:
>
>
> On 2018-08-03 10:19, Huang Shijie wrote:
> > Use dmaenginem_async_device_register to simplify the code:
> >remove dma_async_device_unregister
> >
> > Signed-off-by: Huang Shijie
> > ---
> > drivers/dma/ti/omap-dma.c | 5 +
> > 1 file
On 03-08-18, 10:47, Peter Ujfalusi wrote:
>
>
> On 2018-08-03 10:19, Huang Shijie wrote:
> > Use dmaenginem_async_device_register to simplify the code:
> >remove dma_async_device_unregister
> >
> > Signed-off-by: Huang Shijie
> > ---
> > drivers/dma/ti/omap-dma.c | 5 +
> > 1 file
> On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > > If you have a many-core machine, and have many threads all wanting
> > > to briefly lock a give file (udev is known to do this), you can get
> > > quite poor
> On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > > If you have a many-core machine, and have many threads all wanting
> > > to briefly lock a give file (udev is known to do this), you can get
> > > quite poor
On 26-07-18, 16:00, Baolin Wang wrote:
> From: Eric Long
>
> The Spreadtrum DMA can support the link-list transaction mode, which means
> DMA controller can do transaction one by one automatically once we linked
> these transaction by link-list register.
>
> Signed-off-by: Eric Long
>
On 26-07-18, 16:00, Baolin Wang wrote:
> From: Eric Long
>
> The Spreadtrum DMA can support the link-list transaction mode, which means
> DMA controller can do transaction one by one automatically once we linked
> these transaction by link-list register.
>
> Signed-off-by: Eric Long
>
Hi Adrian, Ulf,
could you please review these patches? Any comments are welcome.
Thanks in advance,
Jisheng
On Mon, 30 Jul 2018 10:42:28 +0800 Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one doesn't
Hi Adrian, Ulf,
could you please review these patches? Any comments are welcome.
Thanks in advance,
Jisheng
On Mon, 30 Jul 2018 10:42:28 +0800 Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one doesn't
In a future patch we will need to differentiate between conflicts that
are "transitive" and those that aren't.
A "transitive" conflict is defined as one where any lock that
conflicts with the first (newly requested) lock would conflict with
the existing lock.
So change posix_locks_conflict(),
When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list. When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending
This functionality will be useful in the next patch, so
split it out from __locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index d06658b2dc7a..fc64016d01ee 100644
---
When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list. When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending
This functionality will be useful in the next patch, so
split it out from __locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index d06658b2dc7a..fc64016d01ee 100644
---
In a future patch we will need to differentiate between conflicts that
are "transitive" and those that aren't.
A "transitive" conflict is defined as one where any lock that
conflicts with the first (newly requested) lock would conflict with
the existing lock.
So change posix_locks_conflict(),
Currently, a lock can block pending requests, but all pending
requests are equal. If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail. This can hurt performance.
So we will allow pending requests to block other requests.
Only the
Currently, a lock can block pending requests, but all pending
requests are equal. If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail. This can hurt performance.
So we will allow pending requests to block other requests.
Only the
struct file lock contains an 'fl_next' pointer which
is used to point to the lock that this request is blocked
waiting for. So rename it to fl_blocker.
The fl_blocked list_head in an active lock is the head of a list of
blocked requests. In a request it is a node in that list.
These are two
struct file lock contains an 'fl_next' pointer which
is used to point to the lock that this request is blocked
waiting for. So rename it to fl_blocker.
The fl_blocked list_head in an active lock is the head of a list of
blocked requests. In a request it is a node in that list.
These are two
This series adds "wake_non_conflicts()" to wake up
any waiters that are being added beneath a lock that they
don't actually conflict with, even though they conflict with a parent
which conflict with the top-level blocker.
Thanks for Bruce for highlighting this issue.
This series hasn't been
This series adds "wake_non_conflicts()" to wake up
any waiters that are being added beneath a lock that they
don't actually conflict with, even though they conflict with a parent
which conflict with the top-level blocker.
Thanks for Bruce for highlighting this issue.
This series hasn't been
piaojun wrote on Thu, Aug 09, 2018:
> > What exact kernel commit are you running?
>
> My kernel commit id 6edf1d4cb0acde, and I replace the 9p code with
> 9p-next. And I wonder if this will work well?
That is somewhere on top of 4.18-rc1 and got merged in 4.18-rc4, which
are close enough so while
piaojun wrote on Thu, Aug 09, 2018:
> > What exact kernel commit are you running?
>
> My kernel commit id 6edf1d4cb0acde, and I replace the 9p code with
> 9p-next. And I wonder if this will work well?
That is somewhere on top of 4.18-rc1 and got merged in 4.18-rc4, which
are close enough so while
On Wed, 8 Aug 2018 15:20:22 -0700
Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 3:00 PM, Joel Fernandes (Google)
> wrote:
> > From: Steven Rostedt
> >
>
> I realize I kept your authorship since I started working based on your patch
> ;-)
>
> Well sorry about that, and you could change it
On Wed, 8 Aug 2018 15:20:22 -0700
Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 3:00 PM, Joel Fernandes (Google)
> wrote:
> > From: Steven Rostedt
> >
>
> I realize I kept your authorship since I started working based on your patch
> ;-)
>
> Well sorry about that, and you could change it
On Wed, Aug 08 2018, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 12:47:22PM -0400, Jeff Layton wrote:
>> On Wed, 2018-08-08 at 11:51 +1000, NeilBrown wrote:
>> > If you have a many-core machine, and have many threads all wanting to
>> > briefly lock a give file (udev is known to do this),
On Wed, Aug 08 2018, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 12:47:22PM -0400, Jeff Layton wrote:
>> On Wed, 2018-08-08 at 11:51 +1000, NeilBrown wrote:
>> > If you have a many-core machine, and have many threads all wanting to
>> > briefly lock a give file (udev is known to do this),
1 - 100 of 1224 matches
Mail list logo
