[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1228810331.12729.59.camel@twins>
Date: Tue, 09 Dec 2008 09:12:11 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Oliver Hartkopp <oliver@...tkopp.net>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
linux-kernel <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC PATCH] hrtimer: removing all ur callback modes
On Tue, 2008-12-09 at 09:07 +0100, Oliver Hartkopp wrote:
> I wouldn't be that sure that all the other sites can cope with it as i
> only detected the problems with my code under heavy load ...
Most other sites only fiddle some bits and do a wakeup of some task or
other - they usually already did spin_lock_irqsave() to protect the
state they poked at.
But sure, testing is always the best way.
> >> Any idea?
> >>
> >
> > What are the timing constraints of your problem? - I assume they are not
> > too aggressive, otherwise you'd not be able to run from softirq, could
> > you run from keventd?
> >
>
> I browsed some code that's using hrtimers and found some hopefully good
> example in drivers/s390/crypto/ap_bus.c : They are using the hrtimer to
> schedule a tasklet which is running in soft-irq context:
>
> http://lxr.linux.no/linux+v2.6.27.8/drivers/s390/crypto/ap_bus.c#L1150
>
> This could also be the correct approach for my sock_queue_rcv_skb()
> problem, right?
In as far as tasklets are correct, yes, that would work for you too.
> Regards,
> Oliver
>
> ps. What is the intended release for this hrtimer cleanup? 2.6.29?
I think so, Thomas, Ingo?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists