On Sat, 2019-03-23 at 11:15 +0100, Peter Zijlstra wrote:
> On Fri, Mar 22, 2019 at 05:57:59PM -0400, Radu Rendec wrote:
> > Hi Everyone,
> >
> > I believe I'm seeing a weird behavior of pick_next_task() where it
> > chooses a lower priority task over a hig
On Sat, 2019-03-23 at 11:15 +0100, Peter Zijlstra wrote:
> On Fri, Mar 22, 2019 at 05:57:59PM -0400, Radu Rendec wrote:
> > Hi Everyone,
> >
> > I believe I'm seeing a weird behavior of pick_next_task() where it
> > chooses a lower priority task over a hig
meantime, I will
experiment with commenting out the optimization (at the expense of a
slower scheduler, of course).
Best regards,
Radu Rendec
lling sysfs_notify_dirent() from a hardware
interrupt handler to wake up a thread and handle the interrupt in user
space.
Signed-off-by: Radu Rendec
---
fs/kernfs/file.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
, this can even
become a case of priority inversion. If a higher priority thread hogs
the CPU, it may delay the kernel worker and in turn the thread that
needs to be notified (which could be a real time thread).
Best regards,
Radu Rendec
Radu Rendec (1):
Improve kernfs_notify() poll notificati
On Thu, 2017-10-12 at 12:54 -0700, Guenter Roeck wrote:
> On Thu, Oct 12, 2017 at 07:15:59PM +0100, Radu Rendec wrote:
> > Thanks for the suggestion! That makes sense. I will start working on
> > converting i6300esb and submit a patch in a few days.
> >
> > By the way
On Wed, 2017-10-11 at 11:46 -0700, Guenter Roeck wrote:
> On Wed, Oct 11, 2017 at 06:46:31PM +0100, Radu Rendec wrote:
> > In a project I'm working on we have a valid use case where we activate
> > both the i6300esb and softdog watchdogs. We always activate i6300esb
>
ta = NULL;
kfree(wd_data);
return err;
Does this look like a good approach? If not, what would you recommend?
In any case, I want to upstream the change, so better ask first :)
Thanks,
Radu Rendec
On Fri, 2017-09-01 at 20:45 +0300, Michael S. Tsirkin wrote:
> On Fri, Sep 01, 2017 at 05:19:53PM +0100, Radu Rendec wrote:
> > On Fri, 2017-09-01 at 18:43 +0300, Michael S. Tsirkin wrote:
> > > On Thu, Aug 31, 2017 at 06:04:04PM +0100, Radu Rendec wrote:
> > &g
On Fri, 2017-09-01 at 18:43 +0300, Michael S. Tsirkin wrote:
> On Thu, Aug 31, 2017 at 06:04:04PM +0100, Radu Rendec wrote:
> > Looking at the code in virtnet_set_link_ksettings, it seems the speed
> > and duplex can be set to any valid value. The driver will "remember"
On Fri, 2017-09-01 at 11:36 +0800, Jason Wang wrote:
>
> On 2017年09月01日 01:04, Radu Rendec wrote:
> > Hello,
> >
> > Looking at the code in virtnet_set_link_ksettings, it seems the speed
> > and duplex can be set to any valid value. The driver will "remembe
lly be set. Could you please
share your opinion on this?
Thank you,
Radu Rendec
On Wed, 2017-03-29 at 20:05 +0200, Ingo Molnar wrote:
> * Randy Dunlap wrote:
>
> > On 03/28/17 10:17, Radu Rendec wrote:
> > > Does anyone still have a copy of Ingo Molnar's mmap-perf.c
> > > program (the
> > > old link is broken)? Would it sti
nyone still have a copy of Ingo Molnar's mmap-perf.c program (the
old link is broken)? Would it still be relevant to use it for measuring
performance in case of PARAVIRT?
Last but not least, has anyone looked into PARAVIRT performance more
recently?
Thank you!
Best regards,
Radu Rendec
14 matches
Mail list logo
