realtime-preempt + reiser4?

realtime-preempt + reiser4?

[Keenan Pepper]

Ingo Molnar's realtime-preempt patches used to be based on the -mm 
kernels, but now they appear to be based on the mainline kernels, so 
they don't support reiser4 (at least until reiser4 is merged into 
mainline, which is looking uncertain as I understand it).
Is realtime-preempt-2.6.10-mm1-V0.7.34-01 the most recent 
realtime-preempt kernel to support reiser4?
How is the latency of the reiser4 code itself?

Keenan

Re: realtime-preempt + reiser4?

[Lee Revell]

On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
> Ingo Molnar's realtime-preempt patches used to be based on the -mm 
> kernels, but now they appear to be based on the mainline kernels, so 
> they don't support reiser4 (at least until reiser4 is merged into 
> mainline, which is looking uncertain as I understand it).

It's not uncertain, the reiser4 people just have to address the issues
that were raised on LKML before it will be merged, just like everyone
else.

> Is realtime-preempt-2.6.10-mm1-V0.7.34-01 the most recent 
> realtime-preempt kernel to support reiser4?
> How is the latency of the reiser4 code itself?

No one ever posted any numbers (to LKML anyway) so we don't know.

Maybe you could apply the broken out reiser4 patches from -mm and the
realtime preempt patches.  Testing with PREEMPT_DESKTOP and latency
tracing enabled will tell you whether reiser4 has any latency hot spots.

Lee

Re: realtime-preempt + reiser4?

[Hans Reiser]

Lee Revell wrote:

>On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
>  
>
>>Ingo Molnar's realtime-preempt patches used to be based on the -mm 
>>kernels, but now they appear to be based on the mainline kernels, so 
>>they don't support reiser4 (at least until reiser4 is merged into 
>>mainline, which is looking uncertain as I understand it).
>>    
>>
>
>It's not uncertain, the reiser4 people just have to address the issues
>that were raised on LKML before it will be merged, just like everyone
>else.
>  
>
Maybe tomorrow the changes will compile.....  they have been written.....

Re: realtime-preempt + reiser4?

[Keenan Pepper]

Lee Revell wrote:
> Maybe you could apply the broken out reiser4 patches from -mm and the
> realtime preempt patches.  Testing with PREEMPT_DESKTOP and latency
> tracing enabled will tell you whether reiser4 has any latency hot spots.

I'm trying this now and it's not exactly trivial; the patches conflict 
in some places so I had to fix by hand. Now I've got it almost compiled 
but it says:

fs/built-in.o: In function `kcond_wait':
: undefined reference to `there_is_no_init_MUTEX_LOCKED_for_RT_semaphores'
fs/built-in.o: In function `kcond_timedwait':
: undefined reference to `there_is_no_init_MUTEX_LOCKED_for_RT_semaphores'

I naively changed these two calls from

init_MUTEX_LOCKED(&name);

to

init_MUTEX(&name);
down(&name);

but I'm not sure if that's right. I guess I'll see when I try to boot it!

Keenan

Re: realtime-preempt + reiser4?

[Lee Revell]

On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
> but I'm not sure if that's right. I guess I'll see when I try to boot it!
> 

The standard fix is to make it a compat_semaphore.  See the list
archives for details.

Lee

Re: realtime-preempt + reiser4?

[Steven Rostedt]

On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:

> 
> I naively changed these two calls from
> 
> init_MUTEX_LOCKED(&name);
> 
> to
> 
> init_MUTEX(&name);
> down(&name);
> 
> but I'm not sure if that's right. I guess I'll see when I try to boot it!

No, since it probably wont be "uped" by the same process.  So what you
want to do is change the definition of name from semaphore to
compat_semaphore, and keep it as init_MUTEX_LOCKED.  And please send
patches to Ingo (I've included him on CC).  Also include Ingo on all RT
related issues, since he is the one maintaining the patch.

Thanks,

-- Steve

Re: realtime-preempt + reiser4?

[Vladimir V. Saveliev]

Hello

Steven Rostedt wrote:
> On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
> 
> 
>>I naively changed these two calls from
>>
>>init_MUTEX_LOCKED(&name);
>>
>>to
>>
>>init_MUTEX(&name);
>>down(&name);
>>
>>but I'm not sure if that's right. I guess I'll see when I try to boot it!
> 
> 
> No, since it probably wont be "uped" by the same process.  So what you
> want to do is change the definition of name from semaphore to
> compat_semaphore, and keep it as init_MUTEX_LOCKED.  And please send
> patches to Ingo (I've included him on CC).  Also include Ingo on all RT
> related issues, since he is the one maintaining the patch.
> 

ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12/reiser4-for-2.6.12-realtime-preempt-2.6.12-final-V0.7.51-29.patch.gz
It applies to 2.6.12 + http://people.redhat.com/mingo/realtime-preempt/older/realtime-preempt-2.6.12-final-V0.7.51-29

Re: realtime-preempt + reiser4?

[Keenan Pepper]

Vladimir V. Saveliev wrote:
> 
> ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12/reiser4-for-2.6.12-realtime-preempt-2.6.12-final-V0.7.51-29.patch.gz 
> 
> It applies to 2.6.12 + 
> http://people.redhat.com/mingo/realtime-preempt/older/realtime-preempt-2.6.12-final-V0.7.51-29 

Ah, this is just what I was looking for. Should have thought to search 
namesys.com.