This looks more like a completion. Actually, completions don't have PI
either, but they are usually OK.
Yeah, true.
When more info becomes available, I will definitely CC the linux-
fsdevel
list. Thanks for letting me know about it. (I usually get confused
by all
the different lists that ar
Hi Zach!
Thanks for the responses.
--
On Tue, 2 Oct 2007, Zach Brown wrote:
>
> On Oct 1, 2007, at 1:39 PM, Peter Zijlstra wrote:
>
> >
> > On Mon, 2007-10-01 at 12:52 -0700, Zach Brown wrote:
> >
> >> Do you have any suggestions for locking constructs that RT would
> >> prefer?
> >
> > Basicall
On Oct 1, 2007, at 1:39 PM, Peter Zijlstra wrote:
On Mon, 2007-10-01 at 12:52 -0700, Zach Brown wrote:
Do you have any suggestions for locking constructs that RT would
prefer?
Basically, anything that maps to a simple mutex. Anything more complex
gets real messy real quick.
I'm worried
On Mon, 2007-10-01 at 12:52 -0700, Zach Brown wrote:
> Do you have any suggestions for locking constructs that RT would prefer?
Basically, anything that maps to a simple mutex. Anything more complex
gets real messy real quick.
Locks that have non-exclusive states become non-deterministic becaus
> Hopefully I will get some attention from those that are responsible for
> fs/direct_io.c
[ many days later, I find this amongst the lkml noise. ]
> This patch converts the i_alloc_sem into a compat_rw_semaphore for the -rt
> patch. Seems that the code in fs/direct_io.c does some nasty logic wi
On Mon, 24 Sep 2007 17:14:26 -0400 (EDT) Steven Rostedt
<[EMAIL PROTECTED]> wrote:
>
> Hopefully I will get some attention from those that are responsible for
> fs/direct_io.c
>
> Ingo and Thomas,
>
> This patch converts the i_alloc_sem into a compat_rw_semaphore for the -rt
> patch. Seems tha
6 matches
Mail list logo