On Mon, Jul 30, 2018 at 07:59:36PM +0200, Pavel Machek wrote:
> Its true I have no interest in psi. But I'm trying to use same kernel
> you are trying to "improve" and I was confused enough by seing
> "CONFIG_PSI". And yes, my association was "pounds per square inch" and
> "what is it doing here".
Hello,
On Mon, Jul 30, 2018 at 10:54:05AM -0700, Randy Dunlap wrote:
> I'd say he's trying to make something that is readable and easier to
> understand for users.
Sure, it's perfectly fine to make those suggestions and discuss but
the counter points have already been discussed (e.g. PSI is a
Hello,
On Mon, Jul 30, 2018 at 10:54:05AM -0700, Randy Dunlap wrote:
> I'd say he's trying to make something that is readable and easier to
> understand for users.
Sure, it's perfectly fine to make those suggestions and discuss but
the counter points have already been discussed (e.g. PSI is a
Hello,
On Mon, Jul 30, 2018 at 07:39:40PM +0200, Pavel Machek wrote:
> > I'd rather have the internal config symbol match the naming scheme in
> > the code, where psi is a shorter, unique token as copmared to e.g.
> > pressure, press, prsr, etc.
>
> I'd do "pressure", really. Yes, psi is
Hello,
On Mon, Jul 30, 2018 at 07:39:40PM +0200, Pavel Machek wrote:
> > I'd rather have the internal config symbol match the naming scheme in
> > the code, where psi is a shorter, unique token as copmared to e.g.
> > pressure, press, prsr, etc.
>
> I'd do "pressure", really. Yes, psi is
On Mon, Jul 30, 2018 at 05:26:45PM +0200, Hans de Goede wrote:
> Hi,
>
> On 30-07-18 17:22, Tejun Heo wrote:
> >On Mon, Jul 30, 2018 at 08:15:47AM -0700, Srinivas Pandruvada wrote:
> >>Hi Tejan,
> >>
> >>On Mon, 2018-07-02 at 12:01 -0700, Sriniv
On Mon, Jul 30, 2018 at 05:26:45PM +0200, Hans de Goede wrote:
> Hi,
>
> On 30-07-18 17:22, Tejun Heo wrote:
> >On Mon, Jul 30, 2018 at 08:15:47AM -0700, Srinivas Pandruvada wrote:
> >>Hi Tejan,
> >>
> >>On Mon, 2018-07-02 at 12:01 -0700, Sriniv
Hello,
On Tue, Jul 31, 2018 at 12:25:04AM +0900, Tetsuo Handa wrote:
> WQ_MEM_RECLAIM guarantees that "struct task_struct" is preallocated. But
> WQ_MEM_RECLAIM does not guarantee that the pending work is started as soon
> as an item was queued. Same rule applies to both WQ_MEM_RECLAIM workqueues
Hello,
On Tue, Jul 31, 2018 at 12:25:04AM +0900, Tetsuo Handa wrote:
> WQ_MEM_RECLAIM guarantees that "struct task_struct" is preallocated. But
> WQ_MEM_RECLAIM does not guarantee that the pending work is started as soon
> as an item was queued. Same rule applies to both WQ_MEM_RECLAIM workqueues
On Mon, Jul 30, 2018 at 08:15:47AM -0700, Srinivas Pandruvada wrote:
> Hi Tejan,
>
> On Mon, 2018-07-02 at 12:01 -0700, Srinivas Pandruvada wrote:
> > Some minor fixes to be able to correctly set devslp register
> > to optimize power.
> >
> > Srinivas Pandruvada (2):
> > ata: libahci: Correct
On Mon, Jul 30, 2018 at 08:15:47AM -0700, Srinivas Pandruvada wrote:
> Hi Tejan,
>
> On Mon, 2018-07-02 at 12:01 -0700, Srinivas Pandruvada wrote:
> > Some minor fixes to be able to correctly set devslp register
> > to optimize power.
> >
> > Srinivas Pandruvada (2):
> > ata: libahci: Correct
Hello,
On Mon, Jul 30, 2018 at 04:46:47PM +0200, Michal Hocko wrote:
> On Mon 30-07-18 23:34:23, Tetsuo Handa wrote:
> > On 2018/07/30 18:32, Michal Hocko wrote:
> [...]
> > > This one is waiting for draining and we are in mm_percpu_wq WQ context
> > > which has its rescuer so no other activity
Hello,
On Mon, Jul 30, 2018 at 04:46:47PM +0200, Michal Hocko wrote:
> On Mon 30-07-18 23:34:23, Tetsuo Handa wrote:
> > On 2018/07/30 18:32, Michal Hocko wrote:
> [...]
> > > This one is waiting for draining and we are in mm_percpu_wq WQ context
> > > which has its rescuer so no other activity
On Fri, Jul 27, 2018 at 01:47:01PM -0700, Srinivas Pandruvada wrote:
> One of the requirement for modern x86 system to enter lowest power mode
> (SLP_S0) is SATA IP block to be off. This is true even during when
> platform is suspended to idle and not only in opportunistic (runtime)
> suspend.
>
On Fri, Jul 27, 2018 at 01:47:01PM -0700, Srinivas Pandruvada wrote:
> One of the requirement for modern x86 system to enter lowest power mode
> (SLP_S0) is SATA IP block to be off. This is true even during when
> platform is suspended to idle and not only in opportunistic (runtime)
> suspend.
>
On Wed, Jul 25, 2018 at 02:50:01PM +0300, Georgi Nikolov wrote:
> I posted a kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=200651 and
> i hope this is the correct place to discuss this.
That's just NORETRY vmalloc allocation failing under memory pressure.
Doesn't have much to do with
On Wed, Jul 25, 2018 at 02:50:01PM +0300, Georgi Nikolov wrote:
> I posted a kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=200651 and
> i hope this is the correct place to discuss this.
That's just NORETRY vmalloc allocation failing under memory pressure.
Doesn't have much to do with
Hello, Andrew.
On Tue, Jul 24, 2018 at 12:29:13PM -0700, Andrew Morton wrote:
> How did you make this happen, btw? Fault injection, or did a small
> GFP_KERNEL allocation fail?
We have a group of machines which are pushing memory really hard and
this actually triggered in prod on several of
Hello, Andrew.
On Tue, Jul 24, 2018 at 12:29:13PM -0700, Andrew Morton wrote:
> How did you make this happen, btw? Fault injection, or did a small
> GFP_KERNEL allocation fail?
We have a group of machines which are pushing memory really hard and
this actually triggered in prod on several of
Fix it by updating delayacct_blkio_end() check @p->delays instead.
Signed-off-by: Tejun Heo
Reported-and-debugged-by: Dave Jones
Cc: Josh Snyder
Fixes: c96f5471ce7d ("delayacct: Account blkio completion on the correct task")
Cc: sta...@vger.kernel.org # v4.15+
---
include/linux/delayacct.h |2
Fix it by updating delayacct_blkio_end() check @p->delays instead.
Signed-off-by: Tejun Heo
Reported-and-debugged-by: Dave Jones
Cc: Josh Snyder
Fixes: c96f5471ce7d ("delayacct: Account blkio completion on the correct task")
Cc: sta...@vger.kernel.org # v4.15+
---
include/linux/delayacct.h |2
On Tue, Jul 17, 2018 at 10:49:35AM +, Corentin Labbe wrote:
> Since ahci_platform_put_resources() use target_pwrs after "devm_" freed
> it, we cannot use devm_kcalloc for allocating target_pwrs.
>
> This reverts commit bd0038b1b4f499d814d8f33a55b1df5ea6cf3b85.
>
> Reported-by: Mikko
On Tue, Jul 17, 2018 at 10:49:35AM +, Corentin Labbe wrote:
> Since ahci_platform_put_resources() use target_pwrs after "devm_" freed
> it, we cannot use devm_kcalloc for allocating target_pwrs.
>
> This reverts commit bd0038b1b4f499d814d8f33a55b1df5ea6cf3b85.
>
> Reported-by: Mikko
Hello, Patrick.
On Mon, Jul 23, 2018 at 06:22:15PM +0100, Patrick Bellasi wrote:
> However, the "best effort" bandwidth control we have for CFS and RT
> can be further improved if, instead of just looking at time spent on
> CPUs, we provide some more hints to the scheduler to know at which
>
Hello, Patrick.
On Mon, Jul 23, 2018 at 06:22:15PM +0100, Patrick Bellasi wrote:
> However, the "best effort" bandwidth control we have for CFS and RT
> can be further improved if, instead of just looking at time spent on
> CPUs, we provide some more hints to the scheduler to know at which
>
Hello,
On Mon, Jul 16, 2018 at 09:29:02AM +0100, Patrick Bellasi wrote:
> The cgroup's CPU controller allows to assign a specified (maximum)
> bandwidth to the tasks of a group. However this bandwidth is defined and
> enforced only on a temporal base, without considering the actual
> frequency a
Hello,
On Mon, Jul 16, 2018 at 09:29:02AM +0100, Patrick Bellasi wrote:
> The cgroup's CPU controller allows to assign a specified (maximum)
> bandwidth to the tasks of a group. However this bandwidth is defined and
> enforced only on a temporal base, without considering the actual
> frequency a
On Wed, Jul 18, 2018 at 07:33:58PM +0200, Claudio wrote:
> This commit adds tests for some of the core functionalities
> of cgroups v2.
>
> The commit adds tests for some core principles of croup V2 API:
Acked-by: Tejun Heo
Thanks, Claudio.
--
tejun
On Wed, Jul 18, 2018 at 07:33:58PM +0200, Claudio wrote:
> This commit adds tests for some of the core functionalities
> of cgroups v2.
>
> The commit adds tests for some core principles of croup V2 API:
Acked-by: Tejun Heo
Thanks, Claudio.
--
tejun
s for only the tasks inside the cgroup.
>
> Signed-off-by: Johannes Weiner
Acked-by: Tejun Heo
Please feel free to route with the rest of the patchset.
Thanks.
--
tejun
s for only the tasks inside the cgroup.
>
> Signed-off-by: Johannes Weiner
Acked-by: Tejun Heo
Please feel free to route with the rest of the patchset.
Thanks.
--
tejun
On Thu, Jul 12, 2018 at 06:31:03PM +0200, Paul Menzel wrote:
> Date: Sun, 8 Jul 2018 09:18:21 +0200
>
> Defining `ATA_DEBUG` there are a lof of messages like below in the log.
>
> [ 16.345472] ata_sg_setup: 1 sg elements mapped
>
> As that is too verbose, only output these messages in
On Thu, Jul 12, 2018 at 06:31:03PM +0200, Paul Menzel wrote:
> Date: Sun, 8 Jul 2018 09:18:21 +0200
>
> Defining `ATA_DEBUG` there are a lof of messages like below in the log.
>
> [ 16.345472] ata_sg_setup: 1 sg elements mapped
>
> As that is too verbose, only output these messages in
On Thu, Jul 12, 2018 at 06:29:44PM +0200, Paul Menzel wrote:
> Date: Sun, 8 Jul 2018 09:11:34 +0200
>
> Defining `ATA_DEBUG` nothing can be really seen, as the log is spammed
> with CDB messages.
>
> Therefore, guard the print by `ATA_VERBOSE_DEBUG`.
>
> Signed-off-by: Paul Menzel
Applied to
On Thu, Jul 12, 2018 at 06:29:44PM +0200, Paul Menzel wrote:
> Date: Sun, 8 Jul 2018 09:11:34 +0200
>
> Defining `ATA_DEBUG` nothing can be really seen, as the log is spammed
> with CDB messages.
>
> Therefore, guard the print by `ATA_VERBOSE_DEBUG`.
>
> Signed-off-by: Paul Menzel
Applied to
On Thu, Jul 12, 2018 at 11:41:28AM +, Corentin Labbe wrote:
> Hello
>
> This patchset fixes some minor problem found when working on supporting
> allwinner R40 AHCI.
>
> Regards
>
> Corentin Labbe (3):
> ata: ahci_platform: correct parameter documentation for
> ahci_platform_shutdown
On Thu, Jul 12, 2018 at 11:41:28AM +, Corentin Labbe wrote:
> Hello
>
> This patchset fixes some minor problem found when working on supporting
> allwinner R40 AHCI.
>
> Regards
>
> Corentin Labbe (3):
> ata: ahci_platform: correct parameter documentation for
> ahci_platform_shutdown
Hello, Linus.
* Jens's patches to expand the usable command depth from 31 to 32
broke sata_fsl due to a subtle command iteration bug. Fixed by
introducing explicit iteration helpers and using the correct
variant.
* On some laptops, enabling LPM by default reportedly led to
occasional
Hello, Linus.
* Jens's patches to expand the usable command depth from 31 to 32
broke sata_fsl due to a subtle command iteration bug. Fixed by
introducing explicit iteration helpers and using the correct
variant.
* On some laptops, enabling LPM by default reportedly led to
occasional
On Mon, Jul 09, 2018 at 05:48:54PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> It is unwise to take spin locks from the handlers of trace events.
> Mainly, because they can introduce lockups, because it introduces locks
> in places that are normally not tested. Worse yet,
On Mon, Jul 09, 2018 at 05:48:54PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> It is unwise to take spin locks from the handlers of trace events.
> Mainly, because they can introduce lockups, because it introduces locks
> in places that are normally not tested. Worse yet,
Hello, Sebastian.
On Wed, Jul 11, 2018 at 01:05:13PM +0200, Sebastian Andrzej Siewior wrote:
> > > We at least used to do this in the kernel - manipulating irqsafe locks
> > > with spin_lock/unlock() if the irq state is known, whether enabled or
> > > disabled, and ISTR lockdep being smart enough
Hello, Sebastian.
On Wed, Jul 11, 2018 at 01:05:13PM +0200, Sebastian Andrzej Siewior wrote:
> > > We at least used to do this in the kernel - manipulating irqsafe locks
> > > with spin_lock/unlock() if the irq state is known, whether enabled or
> > > disabled, and ISTR lockdep being smart enough
(cc'ing Peter and Ingo for lockdep)
Hello, Sebastian.
On Tue, Jul 03, 2018 at 06:45:44PM +0200, Sebastian Andrzej Siewior wrote:
> All callers of cgroup_rstat_flush_locked() acquire cgroup_rstat_lock
> either with spin_lock_irq() or spin_lock_irqsave().
So, irq is always disabled in
(cc'ing Peter and Ingo for lockdep)
Hello, Sebastian.
On Tue, Jul 03, 2018 at 06:45:44PM +0200, Sebastian Andrzej Siewior wrote:
> All callers of cgroup_rstat_flush_locked() acquire cgroup_rstat_lock
> either with spin_lock_irq() or spin_lock_irqsave().
So, irq is always disabled in
Hello, Paul.
On Tue, Jul 03, 2018 at 09:40:44AM -0700, Paul E. McKenney wrote:
> > I will apply this, but be advised that I have not seen that WARN_ON_ONCE()
> > trigger since. :-/
>
> But I get a build error:
>
> kernel/workqueue.o: In function `worker_attach_to_pool':
>
Hello, Paul.
On Tue, Jul 03, 2018 at 09:40:44AM -0700, Paul E. McKenney wrote:
> > I will apply this, but be advised that I have not seen that WARN_ON_ONCE()
> > trigger since. :-/
>
> But I get a build error:
>
> kernel/workqueue.o: In function `worker_attach_to_pool':
>
Hello,
On Tue, Jul 03, 2018 at 03:22:47PM +1000, Benjamin Herrenschmidt wrote:
> +bool kernfs_has_children(struct kernfs_node *kn)
> +{
> + bool has_children = false;
> + struct kernfs_node *pos;
> +
> + /* Lockless shortcut */
> + if (RB_EMPTY_NODE(>rb))
> + return
Hello,
On Tue, Jul 03, 2018 at 03:22:47PM +1000, Benjamin Herrenschmidt wrote:
> +bool kernfs_has_children(struct kernfs_node *kn)
> +{
> + bool has_children = false;
> + struct kernfs_node *pos;
> +
> + /* Lockless shortcut */
> + if (RB_EMPTY_NODE(>rb))
> + return
Hello, Sergey.
On Tue, Jul 03, 2018 at 01:30:21PM +0900, Sergey Senozhatsky wrote:
> Cc-ing Linus, Tejun, Andrew
> [I'll keep the entire lockdep report]
>
> On (07/02/18 19:26), Tetsuo Handa wrote:
> [..]
> > 2018-07-02 12:13:13 192.168.159.129: [ 151.606834] swapper/0/0 is
> > trying to
Hello, Sergey.
On Tue, Jul 03, 2018 at 01:30:21PM +0900, Sergey Senozhatsky wrote:
> Cc-ing Linus, Tejun, Andrew
> [I'll keep the entire lockdep report]
>
> On (07/02/18 19:26), Tetsuo Handa wrote:
> [..]
> > 2018-07-02 12:13:13 192.168.159.129: [ 151.606834] swapper/0/0 is
> > trying to
uch pressure we want to
> do as little IO as possible so we can still make progress on real work
> if we're a throttled cgroup, so just skip readahead if our group is
> under pressure.
>
> Signed-off-by: Josef Bacik
Acked-by: Tejun Heo
Thanks.
--
tejun
uch pressure we want to
> do as little IO as possible so we can still make progress on real work
> if we're a throttled cgroup, so just skip readahead if our group is
> under pressure.
>
> Signed-off-by: Josef Bacik
Acked-by: Tejun Heo
Thanks.
--
tejun
Hello, Paul.
Sorry about the late reply.
On Wed, Jun 20, 2018 at 12:29:01PM -0700, Paul E. McKenney wrote:
> I have hit this WARN_ON_ONCE() in process_one_work:
>
> WARN_ON_ONCE(!(pool->flags & POOL_DISASSOCIATED) &&
>raw_smp_processor_id() != pool->cpu);
>
> This
Hello, Paul.
Sorry about the late reply.
On Wed, Jun 20, 2018 at 12:29:01PM -0700, Paul E. McKenney wrote:
> I have hit this WARN_ON_ONCE() in process_one_work:
>
> WARN_ON_ONCE(!(pool->flags & POOL_DISASSOCIATED) &&
>raw_smp_processor_id() != pool->cpu);
>
> This
On Mon, Jul 02, 2018 at 12:08:45PM -0700, Srinivas Pandruvada wrote:
> From: Srinivas
>
> One of the requirement for modern x86 system to enter lowest power mode
> (SLP_S0) is SATA IP block to be off. This is true even during when
> platform is suspended to idle and not only in opportunistic
On Mon, Jul 02, 2018 at 12:08:45PM -0700, Srinivas Pandruvada wrote:
> From: Srinivas
>
> One of the requirement for modern x86 system to enter lowest power mode
> (SLP_S0) is SATA IP block to be off. This is true even during when
> platform is suspended to idle and not only in opportunistic
On Fri, Jun 22, 2018 at 01:03:07PM +0200, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol,
On Fri, Jun 22, 2018 at 01:03:07PM +0200, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol,
On Fri, Jun 22, 2018 at 01:03:07PM +0200, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol,
On Fri, Jun 22, 2018 at 01:03:07PM +0200, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol,
BDI_DIRTIED => WB_DIRTIED
> BDI_WRITTEN => WB_WRITTEN
>
> Signed-off-by: Greg Thelen
Acked-by: Tejun Heo
Thanks.
--
tejun
BDI_DIRTIED => WB_DIRTIED
> BDI_WRITTEN => WB_WRITTEN
>
> Signed-off-by: Greg Thelen
Acked-by: Tejun Heo
Thanks.
--
tejun
Hello, Peter.
On Tue, Jun 26, 2018 at 05:49:08PM +0200, Peter Zijlstra wrote:
> Well, no, because the Changelog is incomprehensible and the patch
> doesn't really have useful comments, so I'll have to reverse engineer
> the entire thing, and I've just not had time for that.
Just as an additional
Hello, Peter.
On Tue, Jun 26, 2018 at 05:49:08PM +0200, Peter Zijlstra wrote:
> Well, no, because the Changelog is incomprehensible and the patch
> doesn't really have useful comments, so I'll have to reverse engineer
> the entire thing, and I've just not had time for that.
Just as an additional
On Sun, Jul 01, 2018 at 12:15:46PM +0200, Hans de Goede wrote:
> There have been several reports of LPM related hard freezes about once
> a day on multiple Lenovo 50 series models. Strange enough these reports
> where not disk model specific as LPM issues usually are and some users
> with the
On Sun, Jul 01, 2018 at 12:15:46PM +0200, Hans de Goede wrote:
> There have been several reports of LPM related hard freezes about once
> a day on multiple Lenovo 50 series models. Strange enough these reports
> where not disk model specific as LPM issues usually are and some users
> with the
he code a little.
>
> Signed-off-by: Guenter Roeck
Acked-by: Tejun Heo
Thanks.
--
tejun
he code a little.
>
> Signed-off-by: Guenter Roeck
Acked-by: Tejun Heo
Thanks.
--
tejun
On Mon, Jul 02, 2018 at 08:30:22AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Pointers sdev0 and sdev1 are being assigned but are never used hence they
> are redundant and can be removed.
>
> Cleans up clang warnings:
> warning: variable 'sdev0' set but not used
On Mon, Jul 02, 2018 at 08:30:22AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Pointers sdev0 and sdev1 are being assigned but are never used hence they
> are redundant and can be removed.
>
> Cleans up clang warnings:
> warning: variable 'sdev0' set but not used
On Fri, Jun 08, 2018 at 06:26:33PM +0800, John Garry wrote:
> Currently smatch warns of possible Spectre-V1 issue in ahci_led_store():
> drivers/ata/libahci.c:1150 ahci_led_store() warn: potential spectre issue
> 'pp->em_priv' (local cap)
>
> Userspace controls @pmp from following callchain:
>
On Fri, Jun 08, 2018 at 06:26:33PM +0800, John Garry wrote:
> Currently smatch warns of possible Spectre-V1 issue in ahci_led_store():
> drivers/ata/libahci.c:1150 ahci_led_store() warn: potential spectre issue
> 'pp->em_priv' (local cap)
>
> Userspace controls @pmp from following callchain:
>
Hello, Ivan.
On Fri, Jun 15, 2018 at 08:40:02PM +0300, Ivan Zahariev wrote:
> The lazy pids accounting + modern fast CPUs makes the "pids.current"
> metric practically unusable for resource limiting in our case. For a
> test, when we started and ended one single process very quickly, we
> saw
Hello, Ivan.
On Fri, Jun 15, 2018 at 08:40:02PM +0300, Ivan Zahariev wrote:
> The lazy pids accounting + modern fast CPUs makes the "pids.current"
> metric practically unusable for resource limiting in our case. For a
> test, when we started and ended one single process very quickly, we
> saw
Hello,
On Fri, Jun 15, 2018 at 07:07:27PM +0300, Ivan Zahariev wrote:
> I understand all concerns and design decisions. However, having
> RLIMIT_NPROC support combined with "cgroups" hierarchy would be very
> handy.
>
> Does it make sense that you introduce "nproc.current" and
> "nproc.max"
Hello,
On Fri, Jun 15, 2018 at 07:07:27PM +0300, Ivan Zahariev wrote:
> I understand all concerns and design decisions. However, having
> RLIMIT_NPROC support combined with "cgroups" hierarchy would be very
> handy.
>
> Does it make sense that you introduce "nproc.current" and
> "nproc.max"
Hello,
On Fri, Jun 15, 2018 at 05:26:04PM +0300, Ivan Zahariev wrote:
> The standard RLIMIT_NPROC does not suffer from such accounting
> discrepancies at any time.
RLIMIT_NPROC uses a dedicated atomic counter which is updated when the
process is getting reaped; however, that doesn't actually
Hello,
On Fri, Jun 15, 2018 at 05:26:04PM +0300, Ivan Zahariev wrote:
> The standard RLIMIT_NPROC does not suffer from such accounting
> discrepancies at any time.
RLIMIT_NPROC uses a dedicated atomic counter which is updated when the
process is getting reaped; however, that doesn't actually
Hello,
On Mon, Jun 11, 2018 at 11:12:48AM +0200, Jan Kara wrote:
> However this is wrong and so is the patch. The problem is in
> cgwb_bdi_unregister() which does cgwb_kill() and thus drops bdi's
> reference to wb structures before going through the list of wbs again and
> calling wb_shutdown()
Hello,
On Mon, Jun 11, 2018 at 11:12:48AM +0200, Jan Kara wrote:
> However this is wrong and so is the patch. The problem is in
> cgwb_bdi_unregister() which does cgwb_kill() and thus drops bdi's
> reference to wb structures before going through the list of wbs again and
> calling wb_shutdown()
On Wed, Jun 06, 2018 at 09:39:40PM +0200, Mathieu Malaterre wrote:
> Since function `percpu_counter_add' may result in a signed integer overflow
> the result stored in `fbc->count' could be negative. Make sure that
> function `percpu_counter_read_positive' does not return a negative number
> in
On Wed, Jun 06, 2018 at 09:39:40PM +0200, Mathieu Malaterre wrote:
> Since function `percpu_counter_add' may result in a signed integer overflow
> the result stored in `fbc->count' could be negative. Make sure that
> function `percpu_counter_read_positive' does not return a negative number
> in
On Wed, Jun 06, 2018 at 08:14:27AM -0700, Linus Torvalds wrote:
> On Wed, Jun 6, 2018 at 8:04 AM Tejun Heo wrote:
> >
> > The notification implementation isn't super light weight, so the patch
> > ratelimits the notifications by capping minimum notification interval
On Wed, Jun 06, 2018 at 08:14:27AM -0700, Linus Torvalds wrote:
> On Wed, Jun 6, 2018 at 8:04 AM Tejun Heo wrote:
> >
> > The notification implementation isn't super light weight, so the patch
> > ratelimits the notifications by capping minimum notification interval
Hello, Linus.
On Tue, Jun 05, 2018 at 05:13:55PM -0700, Linus Torvalds wrote:
> On Tue, Jun 5, 2018 at 12:22 PM Tejun Heo wrote:
> >
> > * cgroup uses file modified events to notify certain events. A rate
> > limiting mechanism is added.
>
> This "explana
Hello, Linus.
On Tue, Jun 05, 2018 at 05:13:55PM -0700, Linus Torvalds wrote:
> On Tue, Jun 5, 2018 at 12:22 PM Tejun Heo wrote:
> >
> > * cgroup uses file modified events to notify certain events. A rate
> > limiting mechanism is added.
>
> This "explana
to 66448bc274cadedb71fda7d914e7c29d8dead217:
workqueue: move function definitions within CONFIG_SMP block (2018-05-23
11:16:58 -0700)
Mathieu Malaterre (1):
workqueue: move function definitions within CONFIG_SMP block
Tejun Heo (6
to 66448bc274cadedb71fda7d914e7c29d8dead217:
workqueue: move function definitions within CONFIG_SMP block (2018-05-23
11:16:58 -0700)
Mathieu Malaterre (1):
workqueue: move function definitions within CONFIG_SMP block
Tejun Heo (6
)
Andy Shevchenko (1):
rdmacg: Convert to use match_string() helper
Tejun Heo (12):
cgroup: Explicitly remove core interface files
cgroup: Limit event generation frequency
cgroup: Rename kernel/cgroup/stat.c to kernel/cgroup/rstat.c
cgroup
)
Andy Shevchenko (1):
rdmacg: Convert to use match_string() helper
Tejun Heo (12):
cgroup: Explicitly remove core interface files
cgroup: Limit event generation frequency
cgroup: Rename kernel/cgroup/stat.c to kernel/cgroup/rstat.c
cgroup
Hello, Linus.
This is the second part of libata pull request.
* libata has always been limiting the maximum queue depth to 31, 1 set
aside mostly for historical reasons. This didn't use to make much
difference but Jens found out that modern hard drives can actually
perform measurably
Hello, Linus.
This is the second part of libata pull request.
* libata has always been limiting the maximum queue depth to 31, 1 set
aside mostly for historical reasons. This didn't use to make much
difference but Jens found out that modern hard drives can actually
perform measurably
Hello, Linus.
These two are fixes which missed v4.17. I tried to merge these into
libata/for-4.18 but couldn't make "git request-pull" not generate huge
spurious diffstat without merging v4.17 in the middle, so I'm sending
them out as two spearate pull request. Pulling into master should be
Hello, Linus.
These two are fixes which missed v4.17. I tried to merge these into
libata/for-4.18 but couldn't make "git request-pull" not generate huge
spurious diffstat without merging v4.17 in the middle, so I'm sending
them out as two spearate pull request. Pulling into master should be
On Mon, Jun 04, 2018 at 02:01:34PM -0700, Casey Schaufler wrote:
> On 6/1/2018 10:45 AM, Casey Schaufler wrote:
> > Fix memory leak in smack_inode_getsecctx
> >
> > The implementation of smack_inode_getsecctx() made
> > incorrect assumptions about how Smack presents a security
> > context. Smack
On Mon, Jun 04, 2018 at 02:01:34PM -0700, Casey Schaufler wrote:
> On 6/1/2018 10:45 AM, Casey Schaufler wrote:
> > Fix memory leak in smack_inode_getsecctx
> >
> > The implementation of smack_inode_getsecctx() made
> > incorrect assumptions about how Smack presents a security
> > context. Smack
Hello, Michal.
On Mon, Jun 04, 2018 at 03:01:19PM +0200, Michal Hocko wrote:
> > On Fri, Jun 01, 2018 at 01:11:59PM -0500, Eric W. Biederman wrote:
> > > Widening the definition of a process sounds good. The memory control
> > > group code would still need a way to forbid these in cgroup v1
Hello, Michal.
On Mon, Jun 04, 2018 at 03:01:19PM +0200, Michal Hocko wrote:
> > On Fri, Jun 01, 2018 at 01:11:59PM -0500, Eric W. Biederman wrote:
> > > Widening the definition of a process sounds good. The memory control
> > > group code would still need a way to forbid these in cgroup v1
Hello,
On Fri, Jun 01, 2018 at 01:11:59PM -0500, Eric W. Biederman wrote:
> Widening the definition of a process sounds good. The memory control
> group code would still need a way to forbid these in cgroup v1 mode,
> when someone uses the task file.
Yeap, you're right. We'll need memcg's
601 - 700 of 22291 matches
Mail list logo
