RE: [PATCH] Priority-based real-time futexes [Try two, stupid Out

[Perez-Gonzalez, Inaky]

> > I have completed the priority-based futex support; now the code
> > behaves well completely, as futex_fd and poll() work as before, but
> > priority based. So, tasks that are sleeping on a futex get 
> 
> Very useful for real-time tasks...
> 
> I did not think NPTL did real-time threads, though?

Nope so far, as per Ulrich's word, this was one of the things that
held it out; same thing for NGPT. With this I can implement "more"
true real-time in NGPT.
 
> >  - I don't remember if it is safe to call kmalloc with 
> GFP_KERNEL from
> >    inside an spinlock. Common sense says NO to me - just in case, in
> >    the areas where I need it, I use GFP_ATOMIC. Any confirmations?
> 
> No, it is not safe as then you can sleep and consequently deadlock.
> 
> GFP_ATOMIC is the fix but be weary of how much memory you allocate and
> make sure you always check for failure and have some course of action
> there.

Yep - error paths should be ok, but your are right, I don't want to
waste atomic memory. Heavily locked applications might exhaust it.
I'll check that out.

Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
fault]