On Fri, 2020-10-16 at 21:15 +0200, Heiner Kallweit wrote:
>
> But we should spend at least a few thoughts on whether and how the
> irqoff version could be improved. This would have two benefits:
I disagree, using the irqoff version in a place that irqoff is not
always true is a bug.
*Maybe* it wo
On Fri, 2020-10-16 at 17:26 +0300, Vladimir Oltean wrote:
> On Fri, Oct 16, 2020 at 01:34:55PM +0200, Heiner Kallweit wrote:
> > I'm aware of the topic, but missing the benefits of the irqoff version
> > unconditionally doesn't seem to be the best option.
>
> What are the benefits of the irqoff ver
On Fri, 2020-10-16 at 13:34 +0200, Heiner Kallweit wrote:
> On 16.10.2020 13:26, Mike Galbraith wrote:
> >
> > When the kernel is built with PREEMPT_RT or booted with threadirqs,
> > irqs are not disabled when rtl8169_interrupt() is called, inspiring
> > __raise_soft
When the kernel is built with PREEMPT_RT or booted with threadirqs,
irqs are not disabled when rtl8169_interrupt() is called, inspiring
__raise_softirq_irqoff() to gripe. Use plain napi_schedule().
Signed-off-by: Mike Galbraith
---
drivers/net/ethernet/realtek/r8169_main.c |2 +-
1 file
On Tue, 2018-01-09 at 22:26 +0100, Jesper Dangaard Brouer wrote:
>
> I've previously experienced that you can be affected by the scheduler
> granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y):
>
> $ grep -H . /proc/sys/kernel/sched_*_granularity_ns
> /proc/sys/kernel/sched_min_granula
[ 21.219604] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 21.433091] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[ 21.495849] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 22.404040] [ cut here ]
[ 22.404267] WARNING: CPU: 2 PID: 1379 at net/netfilt
On Fri, 2017-09-01 at 11:58 -0700, Kees Cook wrote:
>
> The section stuff is supposed to be a trick to push the error case off
> into the .text.unlikely area to avoid needing a jmp over the handler
> and with possibly some redundancy removal done by the compiler (though
> this appears to be rather
On Fri, 2017-09-01 at 10:12 -0700, Kees Cook wrote:
> On Fri, Sep 1, 2017 at 6:09 AM, Mike Galbraith wrote:
> > On Fri, 2017-09-01 at 08:57 +0200, Mike Galbraith wrote:
> >> On Thu, 2017-08-31 at 11:45 -0700, Kees Cook wrote:
> >> > On Thu, Aug 31, 2017 at 1
On Fri, 2017-09-01 at 08:57 +0200, Mike Galbraith wrote:
> On Thu, 2017-08-31 at 11:45 -0700, Kees Cook wrote:
> > On Thu, Aug 31, 2017 at 10:19 AM, Mike Galbraith wrote:
> > > On Thu, 2017-08-31 at 10:00 -0700, Kees Cook wrote:
> > >>
> > >> Oh! So it&#x
On Thu, 2017-08-31 at 11:45 -0700, Kees Cook wrote:
> On Thu, Aug 31, 2017 at 10:19 AM, Mike Galbraith wrote:
> > On Thu, 2017-08-31 at 10:00 -0700, Kees Cook wrote:
> >>
> >> Oh! So it's gcc-version sensitive? That's alarming. Is this mapping
> >> c
On Thu, 2017-08-31 at 10:00 -0700, Kees Cook wrote:
>
> Oh! So it's gcc-version sensitive? That's alarming. Is this mapping correct:
>
> 4.8.5: WARN, eventual kernel hang
> 6.3.1, 7.0.1: WARN, but continues working
Yeah, that's correct. I find that troubling, simply because this gcc
version has
On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote:
> On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook wrote:
> > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith wrote:
> >> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:
> >>
> >>> Interesting! Can yo
On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote:
> On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook wrote:
> > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith wrote:
> >> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:
> >>
> >>> Interesting! Can yo
On Thu, 2017-06-29 at 15:35 -0400, David Miller wrote:
> From: Mike Galbraith
> Date: Wed, 28 Jun 2017 10:01:00 +0200
>
> > Greetings network wizards,
> >
> > The latest RT explicitly disables CONFIG_NET_RX_BUSY_POLL, thus
> > uncovering $subje
;),
kernel build fails when CONFIG_NET_RX_BUSY_POLL is disabled. Move
napi_hash_add/del() accordingly.
Banged-upon-by: Mike Galbraith
---
include/linux/netdevice.h |8
net/core/dev.c| 12
2 files changed, 16 insertions(+), 4 deletions(-)
--- a/inc
On Thu, 2017-04-06 at 18:13 -0400, Stephen Hemminger wrote:
> Why not replace yield with msleep(1) which gets rid of the inversion
> issues?
That's fine, just not super efficient, if that matters.
-Mike
On Wed, 2017-04-05 at 16:42 -0700, Cong Wang wrote:
> On Tue, Apr 4, 2017 at 10:56 PM, Mike Galbraith wrote:
> > On Tue, 2017-04-04 at 22:19 -0700, Cong Wang wrote:
> > > On Tue, Apr 4, 2017 at 8:55 PM, Mike Galbraith wrote:
> >
> > > > That won't help,
On Wed, 2017-04-05 at 17:31 -0700, Stephen Hemminger wrote:
> On Sun, 02 Apr 2017 06:28:41 +0200
> Mike Galbraith wrote:
>
> > Livelock can be triggered by setting kworkers to SCHED_FIFO, then
> > suspend/resume.. you come back from sleepy-land with a spinning
> > kw
On Wed, 2017-04-05 at 16:55 -0700, Cong Wang wrote:
> On Tue, Apr 4, 2017 at 11:12 PM, Mike Galbraith wrote:
> > On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote:
> > > On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote:
> > > > -
On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote:
> On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote:
> > - while (some_qdisc_is_busy(dev))
> > - yield();
> > + swait_event_timeout(swait,
> > !some_qdisc_is_busy(de
On Tue, 2017-04-04 at 22:19 -0700, Cong Wang wrote:
> On Tue, Apr 4, 2017 at 8:55 PM, Mike Galbraith wrote:
> > That won't help, cond_resched() has the same impact upon a lone
> > SCHED_FIFO task as yield() does.. none.
>
> Hmm? In the comment you quote:
>
>
On Tue, 2017-04-04 at 18:52 -0700, Cong Wang wrote:
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index 1a2f9e9..4725d2f 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -925,7 +925,7 @@ void dev_deactivate_many(struct list_head *head)
> /* Wai
On Tue, 2017-04-04 at 15:39 -0700, Cong Wang wrote:
> Thanks for the report! Looks like a quick solution here is to replace
> this yield() with cond_resched(), it is harder to really wait for
> all qdisc's to transmit all packets.
No, cond_resched() won't help. What I did is below, but I suspect
Greetings network wizards,
Quoting kernel/sched/core.c:
/**
* yield - yield the current processor to other threads.
*
* Do not ever use this function, there's a 99% chance you're doing it wrong.
*
* The scheduler is at all times free to pick the calling task as the most
* eligible task to ru
On Mon, 2016-03-07 at 16:31 +0100, Sebastian Andrzej Siewior wrote:
> On 02/29/2016 05:58 AM, Mike Galbraith wrote:
> > WRT -rt: if dma tasklets really do have hard (ish) constraints, -rt
> > recently "broke" in the same way.. of all softirqs which are deferred
> &g
On Mon, 2016-02-29 at 07:03 -0800, Peter Hurley wrote:
> > If I'm listening properly, the root cause is that there is a timing
> > constraint involved, which is being exposed because one softirq raises
> > another (ew).
>
> Not the case. The softirq is raised from interrupt.
Yeah, saw that on re
On Sun, 2016-02-28 at 18:01 +0100, Francois Romieu wrote:
> Mike Galbraith :
> [...]
> > Hrm, relatively new + tasklet woes rings a bell. Ah, that..
> >
> >
> > What's worse is that at the point where this code was written it was
> > already well known
On Sat, 2016-02-27 at 10:19 -0800, Peter Hurley wrote:
> Hi Eric,
>
> For a while now, we've been struggling to understand why we've been
> observing missed uart rx DMA.
>
> Because both the uart driver (omap8250) and the dmaengine driver
> (edma) were (relatively) new, we assumed there was some
ve pulled.
>
> Fixes: 6ae459bdaaee ("skbuff: Fix skb checksum flag on skb pull")
> Reported-by: Mike Galbraith
> Signed-off-by: Herbert Xu
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 2b0a30a..4398411 100644
> --- a/include/linux/skbuff.h
On Thu, 2015-10-01 at 16:42 +0800, Herbert Xu wrote:
> Mike Galbraith wrote:
> >
> > homer:/usr/local/src/kernel/linux-3.x.git # time strace -vvvfFtT git remote
> > update 2> /strace.out
> > Fetching origin
> >
> > real2m9.164s
> > user
Greetings network wizards,
$subject broke git-daemon here.
homer:/usr/local/src/kernel/linux-3.x.git # time strace -vvvfFtT git remote
update 2> /strace.out
Fetching origin
real2m9.164s
user0m1.616s
sys 0m0.316s
2 minutes of thumb twiddling should have been..
homer:/usr/local/src/
On Tue, 2007-07-24 at 11:25 -0700, Linus Torvalds wrote:
>
> On Tue, 24 Jul 2007, Andrew Morton wrote:
> >
> > I guess this was the bug:
>
> Looks very likely to me. Mike, Alexey, does this fix things for you?
I don't have very much runtime on it yet, but yes, it seems to have.
-Mike
On Tue, 2007-07-24 at 12:01 +0200, Mike Galbraith wrote:
> On Mon, 2007-07-23 at 13:24 -0700, Andrew Morton wrote:
>
> > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that
> > out.
>
> My box bugged during boot the first time I booted 23-rc1,
On Mon, 2007-07-23 at 13:24 -0700, Andrew Morton wrote:
> You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
My box bugged during boot the first time I booted 23-rc1, but nothing
made it to the console, and I didn't have a serial console running. I
didn't have DEBUG_PA
On Tue, 2007-02-27 at 09:33 +0100, Ingo Molnar wrote:
> * Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>
> > Thomas Gleixner napisał(a):
> > > Adrian,
> > >
> > > On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> > >> Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
>
On Wed, 2006-11-29 at 17:08 -0800, Andrew Morton wrote:
> + if (p->backlog_flag == 0) {
> + if (!TASK_INTERACTIVE(p) || expired_starving(rq)) {
> + enqueue_task(p, rq->expired);
> + if (p->static_prio < rq->best
On Tue, 2006-09-19 at 13:36 -0700, Andrew Morton wrote:
> On Tue, 19 Sep 2006 22:25:21 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > > - It took maybe ten hours solid work to get this dogpile vaguely
> > > compiling and limping to a login prompt on x86, x86_64 and powerpc.
> > >
On Tue, 2006-09-19 at 16:33 +0800, Zang Roy-r61911 wrote:
> Hi,
> Does anyone can tell me why some of my patches were blocked in the
> mailing list.
> I do not use attachment. The body of the mail is not exceed 40KB in
> size.
> Roy
A snippet from the 'Bogofilter at VGER' announcment:
38 matches
Mail list logo
