Matthew wrote: > 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 ? > > It means regression testing with any set of applications that involves as much file api as possible and causes intensive IO activity. > 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 > - * > > Ok, its enough. Thanks to everyone! > 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
