Support the special characters escaped by '\' in parser.
This allows user to specify versions directly like below.
=
# ./perf probe -x /lib64/libc-2.25.so malloc_get_state\\@GLIBC_2.2.5
Added new event:
probe_libc:malloc_get_state (on malloc_get_state@GLIBC_2.2.5 in
Support the special characters escaped by '\' in parser.
This allows user to specify versions directly like below.
=
# ./perf probe -x /lib64/libc-2.25.so malloc_get_state\\@GLIBC_2.2.5
Added new event:
probe_libc:malloc_get_state (on malloc_get_state@GLIBC_2.2.5 in
Find versioned symbols correctly from map.
Commit d80406453ad4 ("perf symbols: Allow user probes on
versioned symbols") allows user to find default versioned
symbols (with "@@") in map. However, it did not enable
normal versioned symbol (with "@") for perf-probe.
E.g.
=
# ./perf probe -x
Find versioned symbols correctly from map.
Commit d80406453ad4 ("perf symbols: Allow user probes on
versioned symbols") allows user to find default versioned
symbols (with "@@") in map. However, it did not enable
normal versioned symbol (with "@") for perf-probe.
E.g.
=
# ./perf probe -x
Add __return suffix for function return events
automatically. Without this, user have to give --force
option and will see the number suffix for each event
like "function_1", which is not easy to recognize.
Instead, this adds __return suffix to it automatically.
E.g.
=
# ./perf probe -x
Add __return suffix for function return events
automatically. Without this, user have to give --force
option and will see the number suffix for each event
like "function_1", which is not easy to recognize.
Instead, this adds __return suffix to it automatically.
E.g.
=
# ./perf probe -x
Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
automatic generated event name. This fixes wildcard event
adding like below case;
=
# perf probe -x /lib64/libc-2.25.so malloc*
Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
Error: Failed to add events.
Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
automatic generated event name. This fixes wildcard event
adding like below case;
=
# perf probe -x /lib64/libc-2.25.so malloc*
Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
Error: Failed to add events.
This improve the error message so that user can know
event-name error before writing new events to
kprobe-events interface.
E.g.
==
#./perf probe -x /lib64/libc-2.25.so malloc_get_state*
Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
Error: Failed to add events.
This improve the error message so that user can know
event-name error before writing new events to
kprobe-events interface.
E.g.
==
#./perf probe -x /lib64/libc-2.25.so malloc_get_state*
Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
Error: Failed to add events.
Hi,
Here is the series for probing on versioned symbols
in libraries. This includes 5 patches to fix the
issues discussed on perf-users ML
(https://www.spinics.net/lists/linux-perf-users/msg04637.html)
[1/5] Warn if the event name is invalid. This notices
user that there is internal error
Hi,
Here is the series for probing on versioned symbols
in libraries. This includes 5 patches to fix the
issues discussed on perf-users ML
(https://www.spinics.net/lists/linux-perf-users/msg04637.html)
[1/5] Warn if the event name is invalid. This notices
user that there is internal error
On Tue, 5 Dec 2017, David Rientjes wrote:
> One way to solve the issue is to have two mm flags: one to indicate the mm
> is entering unmap_vmas(): set the flag, do down_write(>mmap_sem);
> up_write(>mmap_sem), then unmap_vmas(). The oom reaper needs this
> flag clear, not MMF_OOM_SKIP, while
On Tue, 5 Dec 2017, David Rientjes wrote:
> One way to solve the issue is to have two mm flags: one to indicate the mm
> is entering unmap_vmas(): set the flag, do down_write(>mmap_sem);
> up_write(>mmap_sem), then unmap_vmas(). The oom reaper needs this
> flag clear, not MMF_OOM_SKIP, while
On Wed, Dec 06, 2017 at 10:31:39AM +0800, Jason Wang wrote:
>
>
> On 2017年12月06日 03:29, Michael S. Tsirkin wrote:
> > Users of ptr_ring expect that it's safe to give the
> > data structure a pointer and have it be available
> > to consumers, but that actually requires an smb_wmb
> > or a
On Wed, Dec 06, 2017 at 10:31:39AM +0800, Jason Wang wrote:
>
>
> On 2017年12月06日 03:29, Michael S. Tsirkin wrote:
> > Users of ptr_ring expect that it's safe to give the
> > data structure a pointer and have it be available
> > to consumers, but that actually requires an smb_wmb
> > or a
It is preferred to use the panel compatible string rather than passing
the LCD timing in the device tree.
So pass the "sii,43wvf1g" compatible string which describes the parallel
LCD.
Also, pass the 'backlight' property as described in
It is preferred to use the panel compatible string rather than passing
the LCD timing in the device tree.
So pass the "sii,43wvf1g" compatible string, which describes the parallel
LCD.
Also pass the 'backlight' property as described in
It is not recommended to place regulators inside "simple-bus", so move
them out.
The motivation for doing this is to make it easier to adding new
regulators.
Signed-off-by: Marco Franchi
---
arch/arm/boot/dts/imx6sl-evk.dts | 85 +---
1
It is preferred to use the panel compatible string rather than passing
the LCD timing in the device tree.
So pass the "sii,43wvf1g" compatible string which describes the parallel
LCD.
Also, pass the 'backlight' property as described in
It is preferred to use the panel compatible string rather than passing
the LCD timing in the device tree.
So pass the "sii,43wvf1g" compatible string, which describes the parallel
LCD.
Also pass the 'backlight' property as described in
It is not recommended to place regulators inside "simple-bus", so move
them out.
The motivation for doing this is to make it easier to adding new
regulators.
Signed-off-by: Marco Franchi
---
arch/arm/boot/dts/imx6sl-evk.dts | 85 +---
1 file changed, 37
2017-12-06 1:09 GMT+08:00 Radim Krcmar :
> 2017-12-04 10:15+0800, Wanpeng Li:
>> 2017-11-14 13:12 GMT+08:00 Rik van Riel :
>> > Currently, every time a VCPU is scheduled out, the host kernel will
>> > first save the guest FPU/xstate context, then load the qemu
2017-12-06 1:09 GMT+08:00 Radim Krcmar :
> 2017-12-04 10:15+0800, Wanpeng Li:
>> 2017-11-14 13:12 GMT+08:00 Rik van Riel :
>> > Currently, every time a VCPU is scheduled out, the host kernel will
>> > first save the guest FPU/xstate context, then load the qemu userspace
>> > FPU context, only to
Hi,
I'd like to understand the synchronization between the oom_reaper's
unmap_page_range() and exit_mmap(). The latter does not hold
mm->mmap_sem: it's supposed to be the last thread operating on the mm
before it is destroyed.
If unmap_page_range() races with unmap_vmas(), we trivially call
Hi,
I'd like to understand the synchronization between the oom_reaper's
unmap_page_range() and exit_mmap(). The latter does not hold
mm->mmap_sem: it's supposed to be the last thread operating on the mm
before it is destroyed.
If unmap_page_range() races with unmap_vmas(), we trivially call
On 12/05/17 10:27, Geert Uytterhoeven wrote:
> Hi Pantelis, Rob, Frank,
>
> Here's a replacement for commit bd80e2555c5c9d45 ("of: overlay: Fix
> cleanup order in of_overlay_apply()"), which was applied by Rob, and
> dropped later.
>
> The first patch fixes the memory leak reported by
On 12/05/17 10:27, Geert Uytterhoeven wrote:
> Hi Pantelis, Rob, Frank,
>
> Here's a replacement for commit bd80e2555c5c9d45 ("of: overlay: Fix
> cleanup order in of_overlay_apply()"), which was applied by Rob, and
> dropped later.
>
> The first patch fixes the memory leak reported by
On Tue, Dec 05, 2017 at 06:05:15PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> > On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > > From: Matthew Wilcox
> > >
> > > I looked through some notes and
On Tue, Dec 05, 2017 at 06:05:15PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> > On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > > From: Matthew Wilcox
> > >
> > > I looked through some notes and decided this was version 4 of
On Wed, Nov 29, 2017 at 4:58 PM, Omar Sandoval wrote:
> diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
> index 98feab7933c7..929ecb7d6b78 100644
> --- a/kernel/sched/wait.c
> +++ b/kernel/sched/wait.c
> @@ -27,7 +27,7 @@ void add_wait_queue(struct wait_queue_head
Cc: Jens Axboe
> On 5 Dec 2017, at 11:48 PM, t...@kernel.org wrote:
>
> Hello, Wang.
>
> On Tue, Dec 05, 2017 at 12:52:54AM -0500, Wang Long wrote:
>> Signed-off-by: Wang Long
>> ---
>> fs/fs-writeback.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>
On Wed, Nov 29, 2017 at 4:58 PM, Omar Sandoval wrote:
> diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
> index 98feab7933c7..929ecb7d6b78 100644
> --- a/kernel/sched/wait.c
> +++ b/kernel/sched/wait.c
> @@ -27,7 +27,7 @@ void add_wait_queue(struct wait_queue_head *wq_head, struct
>
Cc: Jens Axboe
> On 5 Dec 2017, at 11:48 PM, t...@kernel.org wrote:
>
> Hello, Wang.
>
> On Tue, Dec 05, 2017 at 12:52:54AM -0500, Wang Long wrote:
>> Signed-off-by: Wang Long
>> ---
>> fs/fs-writeback.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git
On 2017年12月06日 03:29, Michael S. Tsirkin wrote:
Users of ptr_ring expect that it's safe to give the
data structure a pointer and have it be available
to consumers, but that actually requires an smb_wmb
or a stronger barrier.
In absence of such barriers and on architectures that reorder
On 2017年12月06日 03:29, Michael S. Tsirkin wrote:
Users of ptr_ring expect that it's safe to give the
data structure a pointer and have it be available
to consumers, but that actually requires an smb_wmb
or a stronger barrier.
In absence of such barriers and on architectures that reorder
Hi James,
After merging the scsi tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
drivers/scsi/bfa/bfad_bsg.c: In function 'bfad_im_bsg_vendor_request':
drivers/scsi/bfa/bfad_bsg.c:3137:35: warning: initialization makes pointer from
integer without a cast
Hi James,
After merging the scsi tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
drivers/scsi/bfa/bfad_bsg.c: In function 'bfad_im_bsg_vendor_request':
drivers/scsi/bfa/bfad_bsg.c:3137:35: warning: initialization makes pointer from
integer without a cast
2017-12-01 2:05 GMT+08:00 Radim Krčmář :
> Implementation of the unpinned APIC page didn't update the VMCS address
> cache when invalidation was done through range mmu notifiers.
> This became a problem when the page notifier was removed.
>
> Re-introduce the arch-specific
2017-12-01 2:05 GMT+08:00 Radim Krčmář :
> Implementation of the unpinned APIC page didn't update the VMCS address
> cache when invalidation was done through range mmu notifiers.
> This became a problem when the page notifier was removed.
>
> Re-introduce the arch-specific helper and call it from
On Wed, Dec 6, 2017 at 3:59 AM, Maxime Ripard
wrote:
> Hi,
>
> On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote:
>> On the A64, the MMC module clocks are fixed in the new timing mode,
>> i.e. they do not have a bit to select the mode. These clocks
On Wed, Dec 6, 2017 at 3:59 AM, Maxime Ripard
wrote:
> Hi,
>
> On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote:
>> On the A64, the MMC module clocks are fixed in the new timing mode,
>> i.e. they do not have a bit to select the mode. These clocks have
>> a 2x divider somewhere
Add a Video4Linux2 sensor-level driver for the OmniVision OV7740
VGA camera image sensor.
Changes in v7:
- Add Acked-by tag.
- Fix the wrong handle of default register configuration.
- Add the missed assignment of ov7740->frmsize.
Changes in v6:
- Remove unnecessary #include .
- Remove
Add a Video4Linux2 sensor-level driver for the OmniVision OV7740
VGA camera image sensor.
Changes in v7:
- Add Acked-by tag.
- Fix the wrong handle of default register configuration.
- Add the missed assignment of ov7740->frmsize.
Changes in v6:
- Remove unnecessary #include .
- Remove
On 2017年12月06日 01:02, David Miller wrote:
From: Jason Wang
Date: Mon, 4 Dec 2017 17:31:23 +0800
This patch introduces an eBPF based queue selection method. With this,
the policy could be offloaded to userspace completely through a new
ioctl TUNSETSTEERINGEBPF.
On 2017年12月06日 01:02, David Miller wrote:
From: Jason Wang
Date: Mon, 4 Dec 2017 17:31:23 +0800
This patch introduces an eBPF based queue selection method. With this,
the policy could be offloaded to userspace completely through a new
ioctl TUNSETSTEERINGEBPF.
Signed-off-by: Jason Wang
The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.
Signed-off-by: Songjun Wu
Signed-off-by: Wenyou Yang
---
The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.
Signed-off-by: Songjun Wu
Signed-off-by: Wenyou Yang
---
Changes in v7:
- Fix the wrong handle of default
Add the device tree binding documentation for the ov7740 sensor driver.
Signed-off-by: Wenyou Yang
Acked-by: Rob Herring
---
Changes in v7:
- Add Acked-by tag.
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Explicitly
Add the device tree binding documentation for the ov7740 sensor driver.
Signed-off-by: Wenyou Yang
Acked-by: Rob Herring
---
Changes in v7:
- Add Acked-by tag.
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Explicitly document the "remote-endpoint" property.
On Wed, Dec 06, 2017 at 01:17:52PM +1100, Dave Chinner wrote:
> On Wed, Dec 06, 2017 at 01:53:41AM +, Matthew Wilcox wrote:
> > Huh, you've caught a couple of problems that 0day hasn't sent me yet. Try
> > turning on DAX or TRANSPARENT_HUGEPAGE. Thanks!
>
> Dax is turned on,
On Wed, Dec 06, 2017 at 01:17:52PM +1100, Dave Chinner wrote:
> On Wed, Dec 06, 2017 at 01:53:41AM +, Matthew Wilcox wrote:
> > Huh, you've caught a couple of problems that 0day hasn't sent me yet. Try
> > turning on DAX or TRANSPARENT_HUGEPAGE. Thanks!
>
> Dax is turned on,
On 12/5/17 3:46 PM, Kevin Cernekee wrote:
> Currently, a nlmon link inside a child namespace can observe systemwide
> netlink activity. Filter the traffic so that in a non-init netns,
> nlmon can only sniff netlink messages from its own netns.
>
> Test case:
>
> vpnns -- bash -c "ip link
On 12/5/17 3:46 PM, Kevin Cernekee wrote:
> Currently, a nlmon link inside a child namespace can observe systemwide
> netlink activity. Filter the traffic so that in a non-init netns,
> nlmon can only sniff netlink messages from its own netns.
>
> Test case:
>
> vpnns -- bash -c "ip link
On Wed, Dec 06, 2017 at 01:53:41AM +, Matthew Wilcox wrote:
> Huh, you've caught a couple of problems that 0day hasn't sent me yet. Try
> turning on DAX or TRANSPARENT_HUGEPAGE. Thanks!
Dax is turned on, CONFIG_TRANSPARENT_HUGEPAGE is not.
Looks like nothing is setting
On Wed, Dec 06, 2017 at 01:53:41AM +, Matthew Wilcox wrote:
> Huh, you've caught a couple of problems that 0day hasn't sent me yet. Try
> turning on DAX or TRANSPARENT_HUGEPAGE. Thanks!
Dax is turned on, CONFIG_TRANSPARENT_HUGEPAGE is not.
Looks like nothing is setting
Hi Cyrille,
Thanks a lot for your comments!
> -Original Message-
> From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
> Sent: 2017年12月6日 4:41
> To: Z.q. Hou ; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org; computersforpe...@gmail.com;
>
Hi Cyrille,
Thanks a lot for your comments!
> -Original Message-
> From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
> Sent: 2017年12月6日 4:41
> To: Z.q. Hou ; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org; computersforpe...@gmail.com;
> dw...@infradead.org;
On (12/05/17 17:59), Linus Torvalds wrote:
[..]
> On Tue, Dec 5, 2017 at 5:36 PM, Sergey Senozhatsky
> wrote:
> > I see some %p-s being used in _supposedly_ important output,
> > like arch/x86/mm/fault.c
> >
> > show_fault_oops(struct pt_regs *regs, unsigned
On (12/05/17 17:59), Linus Torvalds wrote:
[..]
> On Tue, Dec 5, 2017 at 5:36 PM, Sergey Senozhatsky
> wrote:
> > I see some %p-s being used in _supposedly_ important output,
> > like arch/x86/mm/fault.c
> >
> > show_fault_oops(struct pt_regs *regs, unsigned long error_code,
> >
Hi Rodrigo,
On Tue, 5 Dec 2017 17:21:54 -0800 Rodrigo Vivi wrote:
>
> I had just written the email for you about this.
> Feel free to ignore that one since you already found the solution
> and sorry for the delay on warning you.
And I should read all my email before
Hi Rodrigo,
On Tue, 5 Dec 2017 17:21:54 -0800 Rodrigo Vivi wrote:
>
> I had just written the email for you about this.
> Feel free to ignore that one since you already found the solution
> and sorry for the delay on warning you.
And I should read all my email before responding to earlier ones
On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox
> >
> > I looked through some notes and decided this was version 4 of the XArray.
> > Last posted two weeks ago, this
On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox
> >
> > I looked through some notes and decided this was version 4 of the XArray.
> > Last posted two weeks ago, this version includes a *lot*
On Wed, Dec 06, 2017 at 12:36:48PM +1100, Dave Chinner wrote:
> > - if (radix_tree_preload(GFP_NOFS))
> > - return -ENOMEM;
> > -
> > INIT_LIST_HEAD(>list_node);
> > elem->key = key;
> >
> > - spin_lock(>lock);
> > - error = radix_tree_insert(>store, key, elem);
> > -
On Wed, Dec 06, 2017 at 12:36:48PM +1100, Dave Chinner wrote:
> > - if (radix_tree_preload(GFP_NOFS))
> > - return -ENOMEM;
> > -
> > INIT_LIST_HEAD(>list_node);
> > elem->key = key;
> >
> > - spin_lock(>lock);
> > - error = radix_tree_insert(>store, key, elem);
> > -
On 2017/12/6 6:39, kan.li...@intel.com wrote:
From: Kan Liang
perf_top__mmap_read has severe performance issue in
Knights Landing/Mill, when monitoring in heavy load system. It costs
several minutes to finish, which is unacceptable.
Currently, perf top is non overwrite
On 2017/12/6 6:39, kan.li...@intel.com wrote:
From: Kan Liang
perf_top__mmap_read has severe performance issue in
Knights Landing/Mill, when monitoring in heavy load system. It costs
several minutes to finish, which is unacceptable.
Currently, perf top is non overwrite mode. For non
On Tue, Dec 5, 2017 at 5:36 PM, Sergey Senozhatsky
wrote:
> I see some %p-s being used in _supposedly_ important output,
> like arch/x86/mm/fault.c
>
> show_fault_oops(struct pt_regs *regs, unsigned long error_code,
> unsigned long address)
> ...
On Tue, Dec 5, 2017 at 5:36 PM, Sergey Senozhatsky
wrote:
> I see some %p-s being used in _supposedly_ important output,
> like arch/x86/mm/fault.c
>
> show_fault_oops(struct pt_regs *regs, unsigned long error_code,
> unsigned long address)
> ...
> printk(KERN_CONT " at
https://pcisig.com/sites/default/files/specification_documents/ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf
Pls also check My Intel Doc# 545845 for the bits fields description.
-Original Message-
From: Bjorn Helgaas [mailto:helg...@kernel.org]
Sent: Wednesday, December 6, 2017
https://pcisig.com/sites/default/files/specification_documents/ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf
Pls also check My Intel Doc# 545845 for the bits fields description.
-Original Message-
From: Bjorn Helgaas [mailto:helg...@kernel.org]
Sent: Wednesday, December 6, 2017
Huh, you've caught a couple of problems that 0day hasn't sent me yet. Try
turning on DAX or TRANSPARENT_HUGEPAGE. Thanks!
> -Original Message-
> From: Dave Chinner [mailto:da...@fromorbit.com]
> Sent: Tuesday, December 5, 2017 8:51 PM
> To: Matthew Wilcox
> Cc:
Huh, you've caught a couple of problems that 0day hasn't sent me yet. Try
turning on DAX or TRANSPARENT_HUGEPAGE. Thanks!
> -Original Message-
> From: Dave Chinner [mailto:da...@fromorbit.com]
> Sent: Tuesday, December 5, 2017 8:51 PM
> To: Matthew Wilcox
> Cc: Matthew Wilcox ; Ross
Fix a compiling error:
...
CC util/libunwind/x86_32.o
In file included from util/libunwind/x86_32.c:33:0:
util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function
'libunwind__x86_reg_id':
util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: error: 'EINVAL'
Fix a compiling error:
...
CC util/libunwind/x86_32.o
In file included from util/libunwind/x86_32.c:33:0:
util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function
'libunwind__x86_reg_id':
util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: error: 'EINVAL'
On Wed, Dec 06, 2017 at 12:28:25AM +0800, Ming Lei wrote:
> On Tue, Dec 05, 2017 at 04:08:20PM +, Bart Van Assche wrote:
> > On Tue, 2017-12-05 at 15:52 +0800, Ming Lei wrote:
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index db9556662e27..1816dd8259b3 100644
> >
On Wed, Dec 06, 2017 at 12:28:25AM +0800, Ming Lei wrote:
> On Tue, Dec 05, 2017 at 04:08:20PM +, Bart Van Assche wrote:
> > On Tue, 2017-12-05 at 15:52 +0800, Ming Lei wrote:
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index db9556662e27..1816dd8259b3 100644
> >
On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox
> >
> > I looked through some notes and decided this was version 4 of the XArray.
> > Last posted two weeks ago, this
On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox
> >
> > I looked through some notes and decided this was version 4 of the XArray.
> > Last posted two weeks ago, this version includes a *lot*
From: Richard Leitner Sent: Tuesday, December 05, 2017 9:26 PM
>Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
>the refclk on and off again during operation (according to their datasheet).
>Nonetheless exactly this behaviour was introduced for power saving
From: Richard Leitner Sent: Tuesday, December 05, 2017 9:26 PM
>Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
>the refclk on and off again during operation (according to their datasheet).
>Nonetheless exactly this behaviour was introduced for power saving reasons
>by
On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> I looked through some notes and decided this was version 4 of the XArray.
> Last posted two weeks ago, this version includes a *lot* of changes.
> I'd like to thank Dave Chinner for
On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> I looked through some notes and decided this was version 4 of the XArray.
> Last posted two weeks ago, this version includes a *lot* of changes.
> I'd like to thank Dave Chinner for his feedback,
Documentation/printk-formats.txt is a candidate for conversion to
ReStructuredText format. Some effort has already been made to do this
conversion even thought the suffix is currently .txt
Changes required to complete conversion
- Add double backticks where needed.
- Add entry to
Documentation/printk-formats.txt is a candidate for conversion to
ReStructuredText format. Some effort has already been made to do this
conversion even thought the suffix is currently .txt
Changes required to complete conversion
- Add double backticks where needed.
- Add entry to
On Tue, Dec 05, 2017 at 04:41:58PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> This eliminates a call to radix_tree_preload().
.
> void
> @@ -431,24 +424,24 @@ xfs_mru_cache_insert(
> unsigned long key,
> struct xfs_mru_cache_elem
On Tue, Dec 05, 2017 at 04:41:58PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> This eliminates a call to radix_tree_preload().
.
> void
> @@ -431,24 +424,24 @@ xfs_mru_cache_insert(
> unsigned long key,
> struct xfs_mru_cache_elem *elem)
> {
> +
On Tue, 2017-12-05 at 06:01 -0500, Jeff Layton wrote:
> On Tue, 2017-12-05 at 13:57 +0800, Aaron Lu wrote:
> > On Wed, Nov 08, 2017 at 03:22:33PM +0800, Aaron Lu wrote:
> > > On Thu, Sep 28, 2017 at 04:02:23PM +0800, kernel test robot wrote:
> > > >
> > > > Greeting,
> > > >
> > > > FYI, we
On Tue, 2017-12-05 at 06:01 -0500, Jeff Layton wrote:
> On Tue, 2017-12-05 at 13:57 +0800, Aaron Lu wrote:
> > On Wed, Nov 08, 2017 at 03:22:33PM +0800, Aaron Lu wrote:
> > > On Thu, Sep 28, 2017 at 04:02:23PM +0800, kernel test robot wrote:
> > > >
> > > > Greeting,
> > > >
> > > > FYI, we
An error occurred during compile because there is no header file
at x86 configure.
Signed-off-by: Anthony Kim
---
drivers/input/touchscreen/hideep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen/hideep.c
An error occurred during compile because there is no header file
at x86 configure.
Signed-off-by: Anthony Kim
---
drivers/input/touchscreen/hideep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen/hideep.c
b/drivers/input/touchscreen/hideep.c
index
Hello,
On (12/05/17 13:22), Linus Torvalds wrote:
[..]
> It's not like those hex numbers were really helping people anyway.
> We've turned off most of them on x86 oops reports long ago (and
> entirely independently of the pointer hashing). Having stared at a lot
> of oopses in my time, the only
On 22:30 Tue 05 Dec, Richard Weinberger wrote:
> On Tue, Nov 21, 2017 at 10:29 AM, Liu, Changcheng
> wrote:
> > fadd2line script should use the binary tool
> > used for the target system.
> >
> > Signed-off-by: Liu Changcheng
> >
> > diff --git
Hello,
On (12/05/17 13:22), Linus Torvalds wrote:
[..]
> It's not like those hex numbers were really helping people anyway.
> We've turned off most of them on x86 oops reports long ago (and
> entirely independently of the pointer hashing). Having stared at a lot
> of oopses in my time, the only
On 22:30 Tue 05 Dec, Richard Weinberger wrote:
> On Tue, Nov 21, 2017 at 10:29 AM, Liu, Changcheng
> wrote:
> > fadd2line script should use the binary tool
> > used for the target system.
> >
> > Signed-off-by: Liu Changcheng
> >
> > diff --git a/scripts/faddr2line b/scripts/faddr2line
> > index
faddr2line hit var unbound error When CROSS_COMPILE
isn't set since nounset option is set in bash script.
Signed-off-by: Liu Changcheng
Reported-by: Richard Weinberger
diff --git a/scripts/faddr2line b/scripts/faddr2line
index
faddr2line hit var unbound error When CROSS_COMPILE
isn't set since nounset option is set in bash script.
Signed-off-by: Liu Changcheng
Reported-by: Richard Weinberger
diff --git a/scripts/faddr2line b/scripts/faddr2line
index 39e07d8..7721d5b 100755
--- a/scripts/faddr2line
+++
tl;dr: Kernels with pagetable isolation using INVPCID compile kernels
0.58% faster than using the deferred CR3 write. This tends to say that
we should leave things as-is and keep using INVPCID, but it's far from
definitive.
If folks have better ideas for a test methodology, or specific workloads
tl;dr: Kernels with pagetable isolation using INVPCID compile kernels
0.58% faster than using the deferred CR3 write. This tends to say that
we should leave things as-is and keep using INVPCID, but it's far from
definitive.
If folks have better ideas for a test methodology, or specific workloads
201 - 300 of 2420 matches
Mail list logo