Re: Comparison of notail and notail,iicache(14) 2.4.19-pre7

[Manuel Krause <manuel.krause@mb.tu-ilmenau.de>]

On 04/27/2002 12:00 AM, Dieter Nützel wrote:

> On Friday 26 April 2002 23:21, Manuel Krause wrote:
> 
>>On 04/26/2002 06:45 PM, Dieter Nützel wrote:
>>
>>>On Friday 26 April 2002 13:41, Yury Yu. Rupasov wrote:
>>>
>>>>Dieter Nützel wrote:
>>>>
>>>>>Manuel Krause wrote:
>>>>>
>>>>>[-]
>>>>>
> 
> [-]
> 
> 
>>>Had that before but Chris and Oleg gave me advice.
>>>I tried it this way:
>>>
>>>/* lock the current transaction */
>>>inline static void lock_journal(struct super_block *p_s_sb) {
>>>  PROC_INFO_INC( p_s_sb, journal.lock_journal );
>>>  debug_lock_break(1);
>>>  conditional_schedule();
>>>  down(&SB_JOURNAL(p_s_sb)->j_lock);
>>>}
>>>
>>>/* unlock the current transaction */
>>>inline static void unlock_journal(struct super_block *p_s_sb) {
>>>  up(&SB_JOURNAL(p_s_sb)->j_lock);
>>>}
>>>
>>>But then it seems to be _NOT_ preempt (+lock-break) save.
>>>System lock up (nothing in the logs, SysRq key didn't work) during
>>>latencytest0.42-png write test. Read test worked.
>>>
>>>Thanks,
>>>	Dieter
>>>
>>Mmh, I made this adjustment in the patch, too, since the first speedup
>>patches had been posted. I really don't know how serious this could be
>>in this code context.
>>
>>I had random hard locks,too, but blamed it to my degenerating hardware
>>so far.
>>
> 
> I think it is hardly hardware related.
> Try without lock-break (only disable it during make xconfig).


I should, if it helped for you. I've lost too much work time inbetween 
for now.

> 
> 
>>Could anyone else advise on preempt+lock-break-awareness here?
>>
> 
> Yura, Chris, Oleg or at least Robert Love :-)
> But Robert hasn't updated the lock-break stuff for some time. He will do it 
> soon.
> 


Yepp. I observed this fact and hope Robert to do so.

> 
>>The linux-2.4.19p6-compound-speedup.patch seems to be another measurable
>>tick faster than Olegs first patchset. Maybe, I'll post some values on
>>my setup over the weekend. I've had one faster run so far but it locked
>>up without log hints... ;-))
>>
> 
> Ha, ha,...:-)
> 
> Then I have one more for you:
> 
> Page coloring patch.
> It gave ~10% speedup on my 1 GHz Athlon II SlotA (0,18µm, L2 512K) for memory 
> intensive apps. But be aware, it locks up randomly. The maintainer is looking 
> for SMP testers 'cause it has something to-do with SMP -> preemption.
> My system is stable but lockup from time to time with the page_color module 
> loaded during "heavy" C and C++ compilations (~40 processes running in 
> parallel).


If I read this correctly I should leave my fingers from it...
Did I make a general mistake? Preempt+ does bring valuable advantages to 
my PIII 933 _uniprocessor_ setup, too.

> 
> Have a nice weekend.
> 
> -Dieter
> 
> BTW I'm working on Win VFAT disk recovery. Two damaged IBM IC35L060AVER07-0 
> costomer disks. One with only a single partition and one with three 
> partitions. Any advice if I should try with dd on the whole disk or every 
> partition?
> 
> 

Maybe we should exchange our actual hdparm and powertweak settings in 
private via phone soon? ;-)

On my current setup I have higher disk troughput rates on small 
partitions (<0.5GB) but dropoffs in the middle of larger ones (~2GB) if 
I trust the ksysguard display. I simply do "dd if=/dev/hda3 bs=1M 
of=/dev/hdd3" after earlier timeless fiddling with bs=xyz and 
xyz~disk-cylinder-size(=16065 * 512 bytes)*2^(?)  did not give 
advantages in the past. I did not do complete disk dd-s so far but had 
many at the end of a dd with the current patch setup and partitions 
 >0.3GB with the conventional bdflush and disk read/write-latency 
parameters. Find your poison!

Have a nice weekend, too! And thanks for your comments, Dieter!

Manuel