Hi Edward, ok, I'm testing it (patch 1) on my production system since yesterday, no adverse effects until now, could you please explain what you exactly mean with "stress test"? which loads does it include ? I'm using this for the following tasks right now: - syncing the portage-tree (lots of small files, at least once a day; a separate reiser4-partition for /usr/portage) - emerging applications (reiser4 on the system-partition; emerge & compilations put relative heavy load on it) - creating stage4-tarballs (creating a tarball out of the running system) - heavy compiling kernels (with -j 25) - usual daily "work" (booting into the OS & launching / working with apps) - updatedb - * if you need more tasks to do let me know and I'll try to include them Thanks Mat On Tue, Aug 12, 2008 at 10:47 PM, Edward Shishkin <edward.shishkin@xxxxxxxxx> wrote: > Matthew wrote: >> Hi Edward, >> >> I somehow did kind of a stress-test to it (all of those patches): >> usual file operations were comparable (compared to the unpatched >> reiser4-tree), but (f)sync-"performance" was somehow abysmal: >> >> whereas it would take 2-5 minutes for the default reiser4 to sync data >> out to disk after a kernel-compilation (issueing 'time sync'), it >> would take >40+ minutes for the patched version to do so, also the hdd >> would be clattering all the time during that >> >> in following cases it would take significant longer: >> - emergency syncing [with magic sysrq key] >> - emergency remount (sometimes it wouldn't even finish) >> - parallel tasks (doing more things at a time / launching several apps at once) >> - hdparm -t /dev/sda (seemingly cache-flushing, heavy clattering >> before & after the output) >> - sync >> - shutdown -h now, reboot >> >> here's the page of the thread where I posted all of the testing-experience: >> http://forums.gentoo.org/viewtopic-t-696253-start-375.html >> >> could it be that Ryan's problems with ext3/ext4 are caused by probable >> inherent problems / bugs with them than rather being a bug in reiser4 >> itself ? >> >> I don't have any partition with ext* filesystems, only reiserfs + >> reiser4 and unfortunately also can't reproduce this behavior ... >> >> > > Guys, patches 2/3, 3/3 of the latest series are wrong and all > manipulations with this stuff (testing, getting stacktraces, etc.) > is just useless wasting your time. > > The patch 1/3 (use-wake_up_process-instead-of-wake_up) > seems to be ok, but it must be stress tested. > If there are any problems specific to this patch, then let me know. > > Thanks, > Edward. > >> the reiser4-devel/reiser4 testing-tree (for zen) can be found on the >> zen-sources git-server: >> http://zen-sources.org/cgi-bin/gitweb.cgi?p=kernel.git;a=summary >> kudos to Ryan, Miguel, Dominic and Corbin :) >> >> keep up the work, guys ! :) >> >> Thanks >> >> Mat >> >> On Tue, Aug 12, 2008 at 8:58 PM, Edward Shishkin >> <edward.shishkin@xxxxxxxxx> wrote: >> >>> Ryan Hope wrote: >>> >>>> This works because the struct "ent" is of type "entd_context" >>>> >>> This logic train goes to a wrong direction ;) >>> >>> >>>> which >>>> has members "wait_queue_head_t wait" and "struct task_struct *tsk". >>>> The function wake_up() takes the parameter wait_queue_head_t the >>>> function wake_up_process() takes task_struct... I figured this would >>>> be a legit switch. I have seen no adverse affects yet. >>>> >>>> >>> Did you stress test it? >>> >>> Thanks, >>> Edward. >>> >>> >>>> -Ryan >>>> >>>> On Fri, Aug 8, 2008 at 4:47 PM, Edward Shishkin >>>> <edward.shishkin@xxxxxxxxx> wrote: >>>> >>>> >>>>> Ryan Hope wrote: >>>>> >>>>> >>>>>> Is this todo really done? >>>>>> >>>>>> >>>>> nop >>>>> >>>>> >>>>> >>>>>>>> As in point 6. in todo list (pub.namesys.com/Reiser4/ToDo ) try to >>>>>>>> replace wake_up() with wake_up_process() >>>>>>>> >>>>>>>> >>>>>> There are still a few more wake_up()'s in the code, the following >>>>>> patch takes care of 2 of them. >>>>>> >>>>>> >>>>> both are not obvious for me, review is needed.. >>>>> >>>>> Edward. >>>>> >>>>> >>>>> >>>>>> diff --git a/fs/reiser4/entd.c b/fs/reiser4/entd.c >>>>>> index a164f5a..355548d 100644 >>>>>> --- a/fs/reiser4/entd.c >>>>>> +++ b/fs/reiser4/entd.c >>>>>> @@ -218,7 +218,7 @@ void reiser4_leave_flush(struct super_block *super) >>>>>> #endif >>>>>> spin_unlock(&ent->guard); >>>>>> if (wake_up_ent) >>>>>> - wake_up(&ent->wait); >>>>>> + wake_up_process(ent->tsk); >>>>>> } >>>>>> >>>>>> #define ENTD_CAPTURE_APAGE_BURST SWAP_CLUSTER_MAX >>>>>> @@ -304,7 +304,7 @@ int write_page_by_ent(struct page *page, struct >>>>>> writeback_control *wbc) >>>>>> ent->nr_todo_reqs++; >>>>>> list_add_tail(&rq.link, &ent->todo_list); >>>>>> if (ent->nr_todo_reqs == 1) >>>>>> - wake_up(&ent->wait); >>>>>> + wake_up_process(ent->tsk); >>>>>> >>>>>> spin_unlock(&ent->guard); >>>>>> >>>>>> >>>>>> -- >>>>>> To unsubscribe from this list: send the line "unsubscribe >>>>>> reiserfs-devel" in >>>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>>> >>>>>> >>>>>> >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >> >> > > -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
