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
