This allows us to check if a remote CPU runs context tracking
(ie: is nohz_full). We'll need that to reliably support "nice"
accounting on kcpustat.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc: Thomas Gleixner
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Wanpeng Li
Cc: Ingo Molnar
Sanitize a bit the functions that do cputime accounting with custom
kcpustat indexes:
* Rename account_system_index_time() to account_system_time_index() to
comply with account_guest/user_time_index()
* Use proper enum cpu_usage_stat type in account_system_time()
* Reorder
Remove the superfluous "is" in the middle of the name. We want to
standardize the naming so that it can be expanded through suffixes:
context_tracking_enabled()
context_tracking_enabled_cpu()
context_tracking_enabled_this_cpu()
Signed-off-by: Frederic Weisbecker
Cc:
Kcpustat is not correctly supported on nohz_full CPUs. The tick doesn't
fire and the cputime therefore doesn't move forward. The issue has shown
up after the vanishing of the remaining 1Hz which has made the issue
visible.
We are solving that with tracking the task running on a CPU through RCU
Record guest as a VTIME state instead of guessing it from VTIME_SYS and
PF_VCPU. This is going to simplify the cputime read side especially as
its state machine is going to further expand in order to fully support
kcpustat on nohz_full.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc:
Now that we have a vtime safe kcpustat accessor, use it to fix frozen
kcpustat values on nohz_full CPUs.
Reported-by: Yauheni Kaliuta
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc: Thomas Gleixner
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Wanpeng Li
Cc: Ingo Molnar
---
Standardize the naming on top of the vtime_accounting_enabled_*() base.
Also make it clear we are checking the vtime state of the
*current* CPU with this function. We'll need to add an API to check that
state on remote CPUs as well, so we must disambiguate the naming.
Signed-off-by: Frederic
On the vtime level, nice updates are currently handled on context
switches. When a task's nice value gets updated while it is sleeping,
the context switch takes into account the new nice value in order to
later record the vtime delta to the appropriate kcpustat index.
We have yet to handle live
This allows us to check if a remote CPU runs vtime accounting
(ie: is nohz_full). We'll need that to reliably support "nice"
accounting on kcpustat.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc: Thomas Gleixner
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Wanpeng Li
Cc: Ingo Molnar
Remove the superfluous "is" in the middle of the name. We want to
standardize the naming so that it can be expanded through suffixes:
context_tracking_enabled()
context_tracking_enabled_cpu()
context_tracking_enabled_this_cpu()
Signed-off-by: Frederic Weisbecker
Cc:
Kcpustat is not correctly supported on nohz_full CPUs. The tick doesn't
fire and the cputime therefore doesn't move forward. The issue has shown
up after the vanishing of the remaining 1Hz which has made the issue
visible.
We are solving that with tracking the task running on a CPU through RCU
Record guest as a VTIME state instead of guessing it from VTIME_SYS and
PF_VCPU. This is going to simplify the cputime read side especially as
its state machine is going to further expand in order to fully support
kcpustat on nohz_full.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc:
Now that we have a vtime safe kcpustat accessor, use it to fix frozen
kcpustat values on nohz_full CPUs.
Reported-by: Yauheni Kaliuta
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc: Thomas Gleixner
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Wanpeng Li
Cc: Ingo Molnar
---
Standardize the naming on top of the vtime_accounting_enabled_*() base.
Also make it clear we are checking the vtime state of the
*current* CPU with this function. We'll need to add an API to check that
state on remote CPUs as well, so we must disambiguate the naming.
Signed-off-by: Frederic
On the vtime level, nice updates are currently handled on context
switches. When a task's nice value gets updated while it is sleeping,
the context switch takes into account the new nice value in order to
later record the vtime delta to the appropriate kcpustat index.
We have yet to handle live
This allows us to check if a remote CPU runs vtime accounting
(ie: is nohz_full). We'll need that to reliably support "nice"
accounting on kcpustat.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc: Thomas Gleixner
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Wanpeng Li
Cc: Ingo Molnar
This function is a leftover from old removal or rename. We can drop it.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc: Thomas Gleixner
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Wanpeng Li
Cc: Ingo Molnar
---
include/linux/context_tracking_state.h | 1 -
1 file changed, 1
In order to make kcpustat vtime aware (ie: work on nohz_full without
freezing), we need to track the task running on the CPU in order to
fetch its vtime delta and add it to the relevant kcpustat field.
The most efficient way to track this task is to use RCU. The task is
assigned on context switch
In order to correctly implement kcpustat under nohz_full, we need to
track the task running on a given CPU and read its vtime state safely,
reliably and locklessly.
This leaves us with tracking and fetching that task under RCU. This will
be done in a further patch. Until then we need to prepare
We need to read the nice value of the task running on any CPU, possibly
remotely, in order to correctly support kcpustat on nohz_full.
Unfortunately we can't just read task_nice(tsk) when tsk runs on another
CPU because its nice value may be concurrently changed. There could be a
risk that a
Standardize the naming on top of the context_tracking_enabled_*() base.
Also make it clear we are checking the context tracking state of the
*current* CPU with this function. We'll need to add an API to check that
state on remote CPUs as well, so we must disambiguate the naming.
Signed-off-by:
This function is a leftover from old removal or rename. We can drop it.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni Kaliuta
Cc: Thomas Gleixner
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Wanpeng Li
Cc: Ingo Molnar
---
include/linux/context_tracking_state.h | 1 -
1 file changed, 1
In order to make kcpustat vtime aware (ie: work on nohz_full without
freezing), we need to track the task running on the CPU in order to
fetch its vtime delta and add it to the relevant kcpustat field.
The most efficient way to track this task is to use RCU. The task is
assigned on context switch
In order to correctly implement kcpustat under nohz_full, we need to
track the task running on a given CPU and read its vtime state safely,
reliably and locklessly.
This leaves us with tracking and fetching that task under RCU. This will
be done in a further patch. Until then we need to prepare
We need to read the nice value of the task running on any CPU, possibly
remotely, in order to correctly support kcpustat on nohz_full.
Unfortunately we can't just read task_nice(tsk) when tsk runs on another
CPU because its nice value may be concurrently changed. There could be a
risk that a
Standardize the naming on top of the context_tracking_enabled_*() base.
Also make it clear we are checking the context tracking state of the
*current* CPU with this function. We'll need to add an API to check that
state on remote CPUs as well, so we must disambiguate the naming.
Signed-off-by:
Record idle as a VTIME state instead of guessing it from VTIME_SYS and
is_idle_task(). This is going to simplify the cputime read side
especially as its state machine is going to further expand in order to
fully support kcpustat on nohz_full.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni
Record idle as a VTIME state instead of guessing it from VTIME_SYS and
is_idle_task(). This is going to simplify the cputime read side
especially as its state machine is going to further expand in order to
fully support kcpustat on nohz_full.
Signed-off-by: Frederic Weisbecker
Cc: Yauheni
Kcpustat (the stats you see for each CPU on /proc/stat) is partly
maintained by the tick, updated by TICK_NSEC every jiffy, the same way
we account the cputime for tasks.
Now in the case of nohz_full, kcpustat doesn't get accounted anymore while
the tick is stopped. Vtime maintains the task
Kcpustat (the stats you see for each CPU on /proc/stat) is partly
maintained by the tick, updated by TICK_NSEC every jiffy, the same way
we account the cputime for tasks.
Now in the case of nohz_full, kcpustat doesn't get accounted anymore while
the tick is stopped. Vtime maintains the task
vtime_account_system() assumes that the target task to account cputime
to is always the current task. This is most often true indeed except on
task switch where we call:
vtime_common_task_switch(prev)
vtime_account_system(prev)
Here prev is the scheduling-out task where
vtime_account_system() decides if we need to account the time to the
system (__vtime_account_system()) or to the guest (vtime_account_guest()).
So this function is a misnommer as we are on a higher level than
"system". All we know when we call that function is that we are
accounting kernel
On context switch we are locking the vtime seqcount of the scheduling-out
task twice:
* On vtime_task_switch_common(), when we flush the pending vtime through
vtime_account_system() / vtime_account_idle()
* On arch_vtime_task_switch() to reset the vtime state.
This is pointless as these
In order to compute the kcpustat delta on a nohz CPU, we'll need to
fetch the task running on that target. Checking that its vtime
state snapshot actually refers to the relevant target involves recording
that CPU under the seqcount locked on task switch.
This is a step toward making kcpustat
Locking the seqcount on idle vtime accounting wasn't thought to be
necessary because the readers of idle cputime don't use vtime (yet).
Now updating vtime expect the related seqcount to be locked so do it
for locking coherency purposes.
Also idle cputime updates use vtime, but idle cputime
vtime_account_system() assumes that the target task to account cputime
to is always the current task. This is most often true indeed except on
task switch where we call:
vtime_common_task_switch(prev)
vtime_account_system(prev)
Here prev is the scheduling-out task where
vtime_account_system() decides if we need to account the time to the
system (__vtime_account_system()) or to the guest (vtime_account_guest()).
So this function is a misnommer as we are on a higher level than
"system". All we know when we call that function is that we are
accounting kernel
On context switch we are locking the vtime seqcount of the scheduling-out
task twice:
* On vtime_task_switch_common(), when we flush the pending vtime through
vtime_account_system() / vtime_account_idle()
* On arch_vtime_task_switch() to reset the vtime state.
This is pointless as these
In order to compute the kcpustat delta on a nohz CPU, we'll need to
fetch the task running on that target. Checking that its vtime
state snapshot actually refers to the relevant target involves recording
that CPU under the seqcount locked on task switch.
This is a step toward making kcpustat
Locking the seqcount on idle vtime accounting wasn't thought to be
necessary because the readers of idle cputime don't use vtime (yet).
Now updating vtime expect the related seqcount to be locked so do it
for locking coherency purposes.
Also idle cputime updates use vtime, but idle cputime
Compiling kernel on an aarch64 server with the latest mainline (rc2) generated
this,
[ 910.263839] WARNING: possible circular locking dependency detected
[ 910.263841] 4.20.0-rc2+ #4 Tainted: GWL
[ 910.263843] --
[
Compiling kernel on an aarch64 server with the latest mainline (rc2) generated
this,
[ 910.263839] WARNING: possible circular locking dependency detected
[ 910.263841] 4.20.0-rc2+ #4 Tainted: GWL
[ 910.263843] --
[
> On Nov 10, 2018, at 12:42 PM, Qian Cai wrote:
>
>
> On 11/10/18 at 11:59 AM, Catalin Marinas wrote:
>
>> On Sat, Nov 10, 2018 at 10:08:10AM -0500, Qian Cai wrote:
>>> On Nov 8, 2018, at 4:23 PM, Qian Cai wrote:
The maximum value for DEBUG_KMEMLEAK_EARLY_LOG_SIZE is only 4, so it
> On Nov 10, 2018, at 12:42 PM, Qian Cai wrote:
>
>
> On 11/10/18 at 11:59 AM, Catalin Marinas wrote:
>
>> On Sat, Nov 10, 2018 at 10:08:10AM -0500, Qian Cai wrote:
>>> On Nov 8, 2018, at 4:23 PM, Qian Cai wrote:
The maximum value for DEBUG_KMEMLEAK_EARLY_LOG_SIZE is only 4, so it
On Wed, Nov 14, 2018 at 05:49:53AM +0900, Stafford Horne wrote:
> On Mon, Nov 12, 2018 at 11:55:44PM +0800, Changbin Du wrote:
> > The third operand of mtspr instruction must be a constraint. To guarantee
> > this condition, function cache_loop() which uses macro mtspr() must be
> > inlined. So
On Wed, Nov 14, 2018 at 05:49:53AM +0900, Stafford Horne wrote:
> On Mon, Nov 12, 2018 at 11:55:44PM +0800, Changbin Du wrote:
> > The third operand of mtspr instruction must be a constraint. To guarantee
> > this condition, function cache_loop() which uses macro mtspr() must be
> > inlined. So
Hi Mark,
After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/spi/spi-npcm-pspi.c: In function 'npcm_pspi_recv':
drivers/spi/spi-npcm-pspi.c:226:17: warning: 'val' may be used uninitialized in
this function [-Wmaybe-uninitialized]
Hi Mark,
After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/spi/spi-npcm-pspi.c: In function 'npcm_pspi_recv':
drivers/spi/spi-npcm-pspi.c:226:17: warning: 'val' may be used uninitialized in
this function [-Wmaybe-uninitialized]
On Tue, Nov 06, 2018 at 06:44:07PM +0530, Balakrishna Godavarthi wrote:
> Hi Marcel,
>
> On 2018-11-06 18:32, Marcel Holtmann wrote:
> > Hi Balakrishna,
> >
> > > > > During hci down we are sending reset command to chip, which
> > > > > is not required for wcn3990, as hdev->shutdown() will turn
On Tue, Nov 06, 2018 at 06:44:07PM +0530, Balakrishna Godavarthi wrote:
> Hi Marcel,
>
> On 2018-11-06 18:32, Marcel Holtmann wrote:
> > Hi Balakrishna,
> >
> > > > > During hci down we are sending reset command to chip, which
> > > > > is not required for wcn3990, as hdev->shutdown() will turn
On 11/13/2018 12:13 PM, Tejun Heo wrote:
> From b1e3aeb11c5e86ee0988a038c4e7682d6beaa977 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Tue, 13 Nov 2018 12:03:33 -0800
>
> * Rename the partition file from "cpuset.sched.partition" to
> "cpuset.cpus.partition".
>
> * When writing to the
On 11/13/2018 12:13 PM, Tejun Heo wrote:
> From b1e3aeb11c5e86ee0988a038c4e7682d6beaa977 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Tue, 13 Nov 2018 12:03:33 -0800
>
> * Rename the partition file from "cpuset.sched.partition" to
> "cpuset.cpus.partition".
>
> * When writing to the
On 11/13/18 5:34 PM, Stefan Berger wrote:
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
I ran the vtpm proxy test suite on this series and got
On 11/13/18 5:34 PM, Stefan Berger wrote:
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
I ran the vtpm proxy test suite on this series and got
On Tue, Nov 06, 2018 at 05:35:26PM +0530, Balakrishna Godavarthi wrote:
> This patch will pull the RTS line high instead of turning off the
> flow control, while changing baudrate of host and chip.
Please don't only describe what is changed, but also why this change
is necessary.
IIUC the BT
On Tue, Nov 06, 2018 at 05:35:26PM +0530, Balakrishna Godavarthi wrote:
> This patch will pull the RTS line high instead of turning off the
> flow control, while changing baudrate of host and chip.
Please don't only describe what is changed, but also why this change
is necessary.
IIUC the BT
On Tue, Nov 13, 2018 at 06:51:50PM +0100, Borislav Petkov wrote:
>On Mon, Nov 12, 2018 at 05:46:43PM +0800, Chao Fan wrote:
>> Imitate setup_acpi_rsdp() for the early_param of 'acpi_rsdp'.
>> KEXEC writes the RSDP pointer to cmdline for EFI booting.
>> So if 'acpi_rsdp' found in cmdline, use it
On Tue, Nov 13, 2018 at 06:51:50PM +0100, Borislav Petkov wrote:
>On Mon, Nov 12, 2018 at 05:46:43PM +0800, Chao Fan wrote:
>> Imitate setup_acpi_rsdp() for the early_param of 'acpi_rsdp'.
>> KEXEC writes the RSDP pointer to cmdline for EFI booting.
>> So if 'acpi_rsdp' found in cmdline, use it
Hi Ian,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc2]
[cannot apply to next-20181113]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
Hi Ian,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc2]
[cannot apply to next-20181113]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 110
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 110
gcc '-Wunused-but-set-variable' warning:
drivers/misc/mic/scif/scif_rma.c: In function 'scif_create_remote_lookup':
drivers/misc/mic/scif/scif_rma.c:373:25: warning:
variable 'vmalloc_num_pages' set but not used [-Wunused-but-set-variable]
'vmalloc_num_pages' should be used to determine if the
gcc '-Wunused-but-set-variable' warning:
drivers/misc/mic/scif/scif_rma.c: In function 'scif_create_remote_lookup':
drivers/misc/mic/scif/scif_rma.c:373:25: warning:
variable 'vmalloc_num_pages' set but not used [-Wunused-but-set-variable]
'vmalloc_num_pages' should be used to determine if the
On Tue, Nov 13 2018 at 8:28pm -0500,
Mike Snitzer wrote:
> On Tue, Nov 13 2018 at 7:51pm -0500,
> Jens Axboe wrote:
>
> > On 11/13/18 5:41 PM, Guenter Roeck wrote:
> > > Hi,
> > >
> > > On Wed, Oct 31, 2018 at 08:36:31AM -0600, Jens Axboe wrote:
> > >> NVMe does round-robin between queues
On Tue, Nov 13 2018 at 8:28pm -0500,
Mike Snitzer wrote:
> On Tue, Nov 13 2018 at 7:51pm -0500,
> Jens Axboe wrote:
>
> > On 11/13/18 5:41 PM, Guenter Roeck wrote:
> > > Hi,
> > >
> > > On Wed, Oct 31, 2018 at 08:36:31AM -0600, Jens Axboe wrote:
> > >> NVMe does round-robin between queues
On 14/11/18 12:43 PM, Russell King - ARM Linux wrote:
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
You could remove the old arch_gettimeoffset API without
On 14/11/18 12:43 PM, Russell King - ARM Linux wrote:
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
You could remove the old arch_gettimeoffset API without
On Tue, Nov 13 2018 at 7:51pm -0500,
Jens Axboe wrote:
> On 11/13/18 5:41 PM, Guenter Roeck wrote:
> > Hi,
> >
> > On Wed, Oct 31, 2018 at 08:36:31AM -0600, Jens Axboe wrote:
> >> NVMe does round-robin between queues by default, which means that
> >> sharing a queue map for both reads and
On Tue, Nov 13 2018 at 7:51pm -0500,
Jens Axboe wrote:
> On 11/13/18 5:41 PM, Guenter Roeck wrote:
> > Hi,
> >
> > On Wed, Oct 31, 2018 at 08:36:31AM -0600, Jens Axboe wrote:
> >> NVMe does round-robin between queues by default, which means that
> >> sharing a queue map for both reads and
Hello,
I need your help to invest in your region.
Hello,
I need your help to invest in your region.
Hello,
I need your help to invest in your region.
Hello,
I need your help to invest in your region.
Hello,
I need your help to invest in your region.
Hello,
I need your help to invest in your region.
Hi Finn,
On 14/11/18 11:11 AM, Finn Thain wrote:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
hardware emulation is a little more complete.
You mean, 40 us resolution, right?
Sorry, typo. Should have been us of
Hi Finn,
On 14/11/18 11:11 AM, Finn Thain wrote:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
hardware emulation is a little more complete.
You mean, 40 us resolution, right?
Sorry, typo. Should have been us of
On Wed, Nov 14, 2018 at 12:55:45AM +, pr-tracker-...@kernel.org wrote:
> The pull request you sent on Sat, 10 Nov 2018 12:12:12 -0600:
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> > for-linus
>
> has been merged into torvalds/linux.git:
>
On Wed, Nov 14, 2018 at 12:55:45AM +, pr-tracker-...@kernel.org wrote:
> The pull request you sent on Sat, 10 Nov 2018 12:12:12 -0600:
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> > for-linus
>
> has been merged into torvalds/linux.git:
>
The pull request you sent on Fri, 9 Nov 2018 17:47:55 +0100:
> https://github.com/ceph/ceph-client.git tags/ceph-for-4.20-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d757a3b01e72368176c5ee580ea17f8c2d185cd7
Thank you!
--
Deet-doot-dot, I am a bot.
> On Nov 12, 2018, at 11:33 PM, Qian Cai wrote:
>
>
>
>> On Nov 10, 2018, at 9:11 AM, Qian Cai wrote:
>>
>> On 11/10/18 at 8:59 AM, Waiman Long wrote:
>>
>>> On 11/09/2018 08:45 PM, Qian Cai wrote:
> Sent: Friday, November 09, 2018 at 5:08 PM
> From: "Waiman Long"
> To:
The pull request you sent on Fri, 9 Nov 2018 15:39:43 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> tags/devicetree-fixes-for-4.20-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aa4330e15c26c5ef8dd184f515c0655db8c6df3a
Thank you!
--
The pull request you sent on Fri, 9 Nov 2018 17:47:55 +0100:
> https://github.com/ceph/ceph-client.git tags/ceph-for-4.20-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d757a3b01e72368176c5ee580ea17f8c2d185cd7
Thank you!
--
Deet-doot-dot, I am a bot.
> On Nov 12, 2018, at 11:33 PM, Qian Cai wrote:
>
>
>
>> On Nov 10, 2018, at 9:11 AM, Qian Cai wrote:
>>
>> On 11/10/18 at 8:59 AM, Waiman Long wrote:
>>
>>> On 11/09/2018 08:45 PM, Qian Cai wrote:
> Sent: Friday, November 09, 2018 at 5:08 PM
> From: "Waiman Long"
> To:
The pull request you sent on Fri, 9 Nov 2018 15:39:43 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> tags/devicetree-fixes-for-4.20-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aa4330e15c26c5ef8dd184f515c0655db8c6df3a
Thank you!
--
The pull request you sent on Sat, 10 Nov 2018 10:04:23 -0800:
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> tags/clk-fixes-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a1aa42f1d8c00a0767afee28d17caafd2a4dd8ff
Thank you!
--
The pull request you sent on Sat, 10 Nov 2018 11:44:54 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/35c55685fc807fb536067602418f4a12dde23987
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Sat, 10 Nov 2018 10:04:23 -0800:
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> tags/clk-fixes-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a1aa42f1d8c00a0767afee28d17caafd2a4dd8ff
Thank you!
--
The pull request you sent on Sat, 10 Nov 2018 11:44:54 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/35c55685fc807fb536067602418f4a12dde23987
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Sat, 10 Nov 2018 12:12:12 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1de4f2ef216dade3b5bd5f5247c4c750a953f51c
Thank you!
--
The pull request you sent on Sat, 10 Nov 2018 12:12:12 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1de4f2ef216dade3b5bd5f5247c4c750a953f51c
Thank you!
--
On 11/13/18 5:41 PM, Guenter Roeck wrote:
> Hi,
>
> On Wed, Oct 31, 2018 at 08:36:31AM -0600, Jens Axboe wrote:
>> NVMe does round-robin between queues by default, which means that
>> sharing a queue map for both reads and writes can be problematic
>> in terms of read servicing. It's much easier
On 11/13/18 5:41 PM, Guenter Roeck wrote:
> Hi,
>
> On Wed, Oct 31, 2018 at 08:36:31AM -0600, Jens Axboe wrote:
>> NVMe does round-robin between queues by default, which means that
>> sharing a queue map for both reads and writes can be problematic
>> in terms of read servicing. It's much easier
Currently, when checking to see if accessing n bytes starting at
address "ptr" will cause a wraparound in the memory addresses,
the check in check_bogus_address() adds an extra byte, which is
incorrect, as the range of addresses that will be accessed is
[ptr, ptr + (n - 1)].
This can lead to
Currently, when checking to see if accessing n bytes starting at
address "ptr" will cause a wraparound in the memory addresses,
the check in check_bogus_address() adds an extra byte, which is
incorrect, as the range of addresses that will be accessed is
[ptr, ptr + (n - 1)].
This can lead to
rate poll queue map" fixes the problem.
Guenter
---
# bad: [220dcf1c6fc97f8873b6d9fe121b80decd4b71a8] Add linux-next specific files
for 20181113
# good: [ccda4af0f4b92f7b4c308d3acc262f4a7e3affad] Linux 4.20-rc2
git bisect start 'HEAD' 'v4.20-rc2'
# good: [b5ae1d7e1bd7cf5dfdef94da5cb69c60c91
rate poll queue map" fixes the problem.
Guenter
---
# bad: [220dcf1c6fc97f8873b6d9fe121b80decd4b71a8] Add linux-next specific files
for 20181113
# good: [ccda4af0f4b92f7b4c308d3acc262f4a7e3affad] Linux 4.20-rc2
git bisect start 'HEAD' 'v4.20-rc2'
# good: [b5ae1d7e1bd7cf5dfdef94da5cb69c60c91
The patch
regulator: bd718x7: Change next state after poweroff to ready
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
The patch
regulator: bd718x7: Change next state after poweroff to ready
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
101 - 200 of 1256 matches
Mail list logo
