You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(52) |
Oct
(6) |
Nov
(59) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(10) |
Feb
(80) |
Mar
(22) |
Apr
(39) |
May
(13) |
Jun
(15) |
Jul
(148) |
Aug
(80) |
Sep
(114) |
Oct
(229) |
Nov
(68) |
Dec
(34) |
2005 |
Jan
(29) |
Feb
(149) |
Mar
(132) |
Apr
(150) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nishanth A. <na...@us...> - 2005-04-18 21:27:55
|
Hello, These results represent running the following benchmarks on a true NUMA machine (16-way with 32GB of RAM). To make the table somewhat less wide, the following convention has been adopted: ***THIS IS DIFFERENT THAN BEFORE*** 1) == 2.6.12-rc1 2) == 2.6.12-rc1 + current CKRM core patches + CONFIG_CKRM=n 3) == 2.6.12-rc1 + current CKRM core patches + CONFIG_CKRM=y 4) == 2.6.12-rc1 + current CKRM core patches + CONFIG_CKRM=y + 100 classes 5) == 2.6.12-rc1 + current CKRM core & memrc patches + CONFIG_CKRM=n As should be clear from the choice of results, I am not able to run with the memory controller enabled on NUMA. Chandra is aware of the issue. As before, instead of posting raw numbers, I have provide only the summary percentage change per each run. kernbench -- 64 threads, 20 iterations percentage of elapsed time relative to mainline ---------------------------------------------------------------------- 1) 100.00 2) 99.86 3) 100.08 4) 100.06 5) 100.01 dbench -- 20 clients, 20 iterations percentage of throughput relative to mainline ---------------------------------------------------------------------- 1) 100.00 2) 99.14 3) 99.82 4) 99.14 5) 100.71 tbench -- 10 clients, 20 iterations percentage of throughput relative to mainline ---------------------------------------------------------------------- 1) 100.00 2) 100.07 3) 99.94 4) 99.54 5) 101.00 SPECjbb [1] -- starting 1 warehouse, by 1s, to 20 warehouses, 20 iterations percentage of score relative to mainline [3] ---------------------------------------------------------------------- 1) 100.00 2) 99.73 3) 109.10 4) 103.63 5) 97.68 SDET [2] -- 20 iterations percentage of throughput relative to mainline # scripts: 1 4 16 64 128 ---------------------------------------------------------------------- 1) 100.00 100.00 100.00 100.00 100.00 2) 99.60 99.91 99.49 99.70 99.99 3) 100.90 100.56 99.55 100.10 100.01 4) 100.68 99.76 99.40 99.97 100.23 5) 100.31 100.52 100.15 100.13 100.16 I have profiler output for all runs in all benchmarks, if anyone cares to see what may have caused certain runs to behave as they did, I can do a diffprofile and mail the results. Thanks, Nish [1] Disclaimer: SPEC(tm) and the benchmark name SPECjbb(tm) are registered trademarks of the Standard Performance Evaluation Corporation. The benchmarking was conducted for research purposes only and were non-compliant with the following deviations from the rules: 1. It was run on hardware that does not meet the SPEC availability-to-the public criteria. The machine was an engineering sample. [2] DISCLAIMER: SPEC(tm) and the benchmark name SDET(tm) are registered trademarks of the Standard Performance Evaluation Corporation. This benchmarking was performed for research purposes only, and the run results are non-compliant and not-comparable with any published results. [3] There seems to be a problem with SPECjbb(tm) on NUMA; each of these runs was labelled invalid, so the score outputs were all estimates (which SPECjbb produced). Thus, I am pretty sure we should disregard the output of SPECjbb for the NUMA run and concentrate on the PPC64 one (which I shall be posting shortly). |
From: Chandra S. <sek...@us...> - 2005-04-15 22:38:19
|
Removed without realizing it. Putting it back. Index: linux-2.6.12-rc1/kernel/ckrm/ckrm_numtasks.c =================================================================== --- linux-2.6.12-rc1.orig/kernel/ckrm/ckrm_numtasks.c +++ linux-2.6.12-rc1/kernel/ckrm/ckrm_numtasks.c @@ -165,6 +165,9 @@ static void numtasks_put_ref_local(struc res = ckrm_get_res_class(core, resid, struct ckrm_numtasks); if (res == NULL) return; + + if (atomic_read(&res->cnt_cur_alloc) == 0) + return; atomic_dec(&res->cnt_cur_alloc); if (atomic_read(&res->cnt_borrowed) > 0) { atomic_dec(&res->cnt_borrowed); |
From: Chandra S. <sek...@us...> - 2005-04-15 22:36:57
|
On Fri, Apr 15, 2005 at 02:01:00PM -0400, Marc E. Fiuczynski wrote: > Hi Chandra, > > Using the various numtask patches does clean up things a bit. I have one > remaining problem: > > On our systems we have the default class (/rcfs/taskclass) and we introduce > a system class (/rcfs/taskclass/system). For whatever reason, the cur_alloc > value in the default stats file is shown as -569. Before it would not hit a > negative number, because put_ref_local would check whether it would > decrement below zero and instead just printk a warning message. Oops.... didn't mean to delete it(as I said I was just trying to clean up)... will send out a patch over 07c-numtasks_cleanup Ideally this should not be there... I didn't get to debug/fix it yet. > > I am not sure what is going on. What would you recommend is the right > approach to debug this? My guess is that it happens thru numtasks_change_resclass().. So moving a task from a class to another will show this problem. > > Marc > -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 17:51:04
|
On Thu, Apr 14, 2005 at 10:40:19AM -0700, Chandra Seetharaman wrote: > > -- > > ---------------------------------------------------------------------- > Chandra Seetharaman | Be careful what you choose.... > - sek...@us... | .......you may get it. > ---------------------------------------------------------------------- > Function returns without unlocking the readllock in a case. > This patch fixes it. > > This patch applies over PATCH 3/5 of Gerrit's recent patchset. reread the above line with "PATCH 3/8" instead of "PATCH 3/5" :) > > Index: linux-2.6.12-rc1/kernel/ckrm/ckrm.c > =================================================================== > --- linux-2.6.12-rc1.orig/kernel/ckrm/ckrm.c > +++ linux-2.6.12-rc1/kernel/ckrm/ckrm.c > @@ -106,6 +106,7 @@ void *ckrm_classobj(char *classname, int > if (core->name && !strcmp(core->name, classname)) { > /* FIXME: should grep reference. */ > *classtype_id = ctype->type_id; > + read_unlock(&ckrm_class_lock); > return core; > } > } -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 17:50:28
|
-- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 17:48:00
|
-- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Marc E. F. <mef@CS.Princeton.EDU> - 2005-04-14 07:28:21
|
That seems to take care of the funny negative numbers. Marc > -----Original Message----- > From: ckr...@li... > [mailto:ckr...@li...]On Behalf Of Chandra > Seetharaman > Sent: Wednesday, April 13, 2005 9:30 PM > To: ckr...@li... > Subject: Re: [ckrm-tech] ckrm cpu controller problems on laptop suspend > > > On Wed, Apr 13, 2005 at 04:18:49PM -0400, Marc E. Fiuczynski wrote: > > Can you try the attached patch. > > Thanks, > > chandra > > Chandra, > > > > There is something fishy going on with the cnt_guar and > cnt_unused values. > > > > In /rcfs/taskclass/stats the values are set to 131072. > > > > In any of the classes below (/rcfs/taskclass/foo/stats) the values > > are -171801314 and -343600006, respectively. This doesn't look right. > > Could it be that these values are computed through some sort of > > multiplication with CKRM_SHARE_UNCHANGED and CKRM_SHARE_DONTCARE in > > recalc_and_propagte? > > > > Marc > > > > -- > > ---------------------------------------------------------------------- > Chandra Seetharaman | Be careful what you choose.... > - sek...@us... | .......you may get it. > ---------------------------------------------------------------------- > |
From: Chandra S. <sek...@us...> - 2005-04-14 03:12:06
|
On Thu, Mar 03, 2005 at 12:08:19PM -0800, Gerrit Huizenga wrote: > > Hi Chandra, a few comments interpersed... But can you generally kill > off the C++ comments? They are mixed in quite inconsistently and > it makes it a little odd to read at times. fixed > > Lots of extra { }'s included. Please strip those out in all 5 > patches. fixed > > > Should this be on a new line, e.g.: > > obj-$(CONFIG_CKRM_RBCE) += rbce/ fixed > > > +#define MAGIC_CE_DIR "ce" > > +#define MAGIC_RULES_DIR "rules" > > +#define MAGIC_RBCE_INFO "rbce_info" > > +#define MAGIC_RBCE_STATE "rbce_state" > > +#define MAGIC_RBCE_TAG "rbce_tag" > > + > > Weren't we going to rename this MAGIC_ to something like > CONFFILE_ ? And shouldn't these defines be in a header rather than > the .c file? fixed > > > + > > + line = (char *)kmalloc(len + 1, GFP_KERNEL); > > Cast unnecessary. fixed > > > + len = rc; > > + } > > Too many { }'s - not need to surround a single statement. I think > there are four extra sets here. fixed > > + if (!strcmp(file->f_dentry->d_name.name, MAGIC_RBCE_TAG)) { > > + return -EPERM; > > + } > > Unnecessary { }'s. fixed > > + (for "." entry) */ > > Can you use the > > /* > * Comment, Line 1 > * Comment, Line 2 > */ > > Format for multiline comments and /* comment */ for inline or single > line comments? I just like a little consistency in my own life. ;-) > fixed > > > +/* SMP-safe */ > > Why? fixed > > + return -EINVAL; > > + } > > Comments, { }'s. fixed > > + > > +// CE allows only the rules directory to be created > > Back and forth, C++, C style comments. I like C style. ;-) fixed > > > +int rbce_mkdir(struct inode *dir, struct dentry *dentry, int mode) > > +{ > > + int retval = -EINVAL; > > + > > + struct dentry *pd = > > + list_entry(dir->i_dentry.next, struct dentry, d_alias); > > + > > + // Allow only /rcfs/ce and ce/rules > > Allow them for what? Or allow files to only be created in > this directories? Go for a complete (short is fine) sentence. Comments > are good but only when they bring enlightenment. made the comments clear > > > + > > +// CE doesn't allow deletion of directory > > Which directory? Any directory? yes, any directory.. as of now there is only one directory rules, which is automatically created. > > > + > > +/******************************* Magic files ********************/ > > Magic, hmm. Is this a sufficiently advanced technology? :) fixed > > > + * for cleanliness. > > Okay - I don't get this. Why are all these messages in the kernel? > Is this an in-kernel help file? Ugh. I don't think I like this. Does > this really have to be here? as discussed, removed this and added it in the documentation directory > > @@ -0,0 +1,68 @@ > > +/* > > + * rbce internal header file. > > Are there some headers that are not internal? Are they supposed to > be used by user level applications? Or by whom? Can you call out those > header files and ensure that they have *only* definitions/declarations > needed by the scope in which they are to be used? And then this > "internal" name could be made into something more descriptive. I meant to mean it as "internal to the rbce module". It is being as filenames in some other parts of the kernel too.... Filename has not been changed. Suggestions for new name welcome. > > > +#ifndef _RBCE_INTERNAL_H > > +#define _RBCE_INTERNAL_H > > + > > +#define DEBUG > > Do you still need this in here? gone > > > +// Rule handling data structures. > > +struct named_obj_hdr { > > + struct list_head link; > > + int referenced; > > + char *name; > > +}; > > Okay, the comment isn't very clear and the structure name is > even less clear. Is this an rbce_rule ? made comment clear... it is used as a header for both rule and class data structure that are internal to rbce. > > > +extern int rbce_set_tasktag(int, char *); > > +extern int rbce_rename_rule(const char *, const char *); > > Why are these all "char *"? Shouldn't they be passing around > rule structures or something? No, I haven't read ahead yet. ;) no, they are char *, these are interfaces from the filesystem to the main functionality. > > > + > > + printk(KERN_INFO "<1>\nInstalling \'%s\' module\n", modname); > > Isn't the KERN_INFO and <1> redundent? fixed > > > + rcfs_unregister_engine(&rbce_rcfs_ecbs); > > + printk(KERN_ERR "<1>%s: error installing rc=%d line=%d\n", > > Why the <1> again? > > And this seems inconsistent and/or wrong - you have a return higher > in the function and one goto. Only one way to get here, so __LINE__ > can only have one value... fixed > > > + __FUNCTION__, rc, line); > > + return rc; > > +} > > + > > +void exit_rbce(void) > > +{ > > + printk(KERN_INFO "<1>Removing \'%s\' module\n", modname); > > I'm still thinking KERN_INFO and <1> are redundent. Prove me > wrong if you want... fixed > > gerrit -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 03:03:34
|
-- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 03:03:22
|
-- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 03:02:58
|
-- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 03:02:38
|
-- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 03:02:20
|
-- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Chandra S. <sek...@us...> - 2005-04-14 03:01:36
|
Hello All, Here is the patchset for RBCE that applies over the patchset which was sent on ckrm-tech and lkml few days back against 2.6.12-rc1 Fixed few bugs and some changes accoring to Gerrit's comments. The ones that are not addressed, I 'll reply to the original mail ------------------------------ Patches are: 09-01-rbce_fs: Just the file system interface of RBCE, with stubs for rules etc., 09-02-rbce_fs-main: Provides the functionality needed by rcfs interface. No classification yet. 09-03-rbce_main-opt: Provides optimization by maintaining the classification information in some internal vectors. No classification yet. 09-04-rbce_opt-core: Connects RBCE with CKRM core. Provides full functionality of RBCE. 09-05-rbce_core-crbce: Provides CRBCE. CRBCE allows per-process delay data and additional user level monitoring support. regards, chandra |
From: Chandra S. <sek...@us...> - 2005-04-14 01:37:58
|
On Wed, Apr 13, 2005 at 04:18:49PM -0400, Marc E. Fiuczynski wrote: Can you try the attached patch. Thanks, chandra > Chandra, > > There is something fishy going on with the cnt_guar and cnt_unused values. > > In /rcfs/taskclass/stats the values are set to 131072. > > In any of the classes below (/rcfs/taskclass/foo/stats) the values > are -171801314 and -343600006, respectively. This doesn't look right. > Could it be that these values are computed through some sort of > multiplication with CKRM_SHARE_UNCHANGED and CKRM_SHARE_DONTCARE in > recalc_and_propagte? > > Marc > -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Marc E. F. <mef@CS.Princeton.EDU> - 2005-04-13 20:18:59
|
Chandra, There is something fishy going on with the cnt_guar and cnt_unused values. In /rcfs/taskclass/stats the values are set to 131072. In any of the classes below (/rcfs/taskclass/foo/stats) the values are -171801314 and -343600006, respectively. This doesn't look right. Could it be that these values are computed through some sort of multiplication with CKRM_SHARE_UNCHANGED and CKRM_SHARE_DONTCARE in recalc_and_propagte? Marc |
From: Marc E. F. <mef@CS.Princeton.EDU> - 2005-04-12 21:20:00
|
I am glad to hear that it works. I was worried that just setting the PF_NOFREEZE flag that the cpu_monitord thread would not be resumed after you resume the system. Marc > -----Original Message----- > From: Shailabh Nagar [mailto:na...@wa...] > Sent: Tuesday, April 12, 2005 5:03 PM > To: Marc E. Fiuczynski > Cc: ckrm-tech > Subject: Re: [ckrm-tech] ckrm cpu controller problems on laptop suspend > > > Marc E. Fiuczynski wrote: > > Shailabh, > > > > I am wondering if it might be enough to set the PF_NOFREEZE flag for the > > ckrm_cpu_monitord thread. I tried this in our kernel, but now > it crashes in > > some other low-level disk dump portion of the kernel. I'll > need to try this > > with a vanilla 2.6.1x kernel with E17. Maybe that's enough. > Maybe one has > > to do the type of kthread management as done in kernel/softirq.c. > > > > Cheers, > > Marc > > > Yes, this does seem to solve the problem. > I tried linux-2.6.11 with and without the following patch. In the former > case, I get the same error on suspend as you saw. With the patch, > suspend and resume worked ok. > > Thanks for catching this ! > -- Shailabh > > > Signed-off by Shailabh Nagar > > Index: linux-2.6.11.7-e17/kernel/ckrm/ckrm_cpu_monitor.c > =================================================================== > --- linux-2.6.11.7-e17.orig/kernel/ckrm/ckrm_cpu_monitor.c > 2005-04-12 16:54:41.942882520 -0400 > +++ linux-2.6.11.7-e17/kernel/ckrm/ckrm_cpu_monitor.c 2005-04-12 > 16:56:52.417047432 -0400 > @@ -1256,6 +1256,7 @@ static int thread_exit = 0; > static int ckrm_cpu_monitord(void *nothing) > { > daemonize("ckrm_cpu_ctrld"); > + current->flags |= PF_NOFREEZE; > printk("cpu_monitord started\n"); > thread_exit = 0; > for (;;) { |
From: Shailabh N. <na...@wa...> - 2005-04-12 21:03:12
|
Marc E. Fiuczynski wrote: > Shailabh, > > I am wondering if it might be enough to set the PF_NOFREEZE flag for the > ckrm_cpu_monitord thread. I tried this in our kernel, but now it crashes in > some other low-level disk dump portion of the kernel. I'll need to try this > with a vanilla 2.6.1x kernel with E17. Maybe that's enough. Maybe one has > to do the type of kthread management as done in kernel/softirq.c. > > Cheers, > Marc Yes, this does seem to solve the problem. I tried linux-2.6.11 with and without the following patch. In the former case, I get the same error on suspend as you saw. With the patch, suspend and resume worked ok. Thanks for catching this ! -- Shailabh Signed-off by Shailabh Nagar Index: linux-2.6.11.7-e17/kernel/ckrm/ckrm_cpu_monitor.c =================================================================== --- linux-2.6.11.7-e17.orig/kernel/ckrm/ckrm_cpu_monitor.c 2005-04-12 16:54:41.942882520 -0400 +++ linux-2.6.11.7-e17/kernel/ckrm/ckrm_cpu_monitor.c 2005-04-12 16:56:52.417047432 -0400 @@ -1256,6 +1256,7 @@ static int thread_exit = 0; static int ckrm_cpu_monitord(void *nothing) { daemonize("ckrm_cpu_ctrld"); + current->flags |= PF_NOFREEZE; printk("cpu_monitord started\n"); thread_exit = 0; for (;;) { |
From: Marc E. F. <mef@CS.Princeton.EDU> - 2005-04-12 20:19:35
|
> you are not able to fork ? that is bad... will look into it. Right... I cannot fork after a while. > It may not be related to forkrate controller as that is > just a counter Right... it is a counter that is used in some logic in numtasks_get_ref_local() to check when to stop forks. > which clears out after the specified time. Ok... I am not saying forkrate is the culprit. It is just that after some time period (typically measured on the order of many hours or days), we can no longer fork. The main change in our kernel to this end is the numtask controller. So I am assuming that something there is wrong and the primariy code change has to do with forkrate stuff. Marc |
From: Chandra S. <sek...@us...> - 2005-04-12 19:53:22
|
On Tue, Apr 12, 2005 at 03:48:51PM -0400, Marc E. Fiuczynski wrote: > Chandra, > > Eyeballing the code I cannot figure out what might be causing the problem we > are observing. Specifically, all code incrementing or decrementing the > cur_cnt_alloc is unchanged. Mostly what seems to have been added is the > forkrate support. Any way, we see the > > numtasks_put_ref: Trying to decrement counter below 0 > > for a while and then after a day or so of uptime we can no longer fork. So > maybe the bug really has to do with the forkrate support rather than the > above printk. you are not able to fork ? that is bad... will look into it. It may not be related to forkrate controller as that is just a counter which clears out after the specified time. > > Is the forkrate support on by default? yes... > > Marc > > > > > -----Original Message----- > > From: ckr...@li... > > [mailto:ckr...@li...]On Behalf Of Marc E. > > Fiuczynski > > Sent: Monday, April 11, 2005 11:12 PM > > To: Chandra Seetharaman; ckr...@li... > > Subject: RE: [ckrm-tech] ckrm cpu controller problems on laptop suspend > > > > > > Chandra, > > > > We are seeing a number of these messages: > > > > numtasks_put_ref: Trying to decrement counter below 0 > > > > We did not see them before with the E16 version of the numtask controller. > > > > Marc > > > > > -----Original Message----- > > > From: ckr...@li... > > > [mailto:ckr...@li...]On Behalf Of Chandra > > > Seetharaman > > > Sent: Monday, April 11, 2005 3:20 PM > > > To: ckr...@li... > > > Subject: Re: [ckrm-tech] ckrm cpu controller problems on laptop suspend > > > > > > > > > On Mon, Apr 11, 2005 at 02:38:32PM -0400, Marc E. Fiuczynski wrote: > > > > Hi Shailabh, > > > > > > > > Doing a cvs upgrade will give you a kernel that has exhibits > > > this problem. > > > > > > > > It also exhibits a separate numtasks problem that started to > > > appear after I > > > > upgraded to the E17 version of that controller, which I am > > > debugging right > > > > now. > > > > > > Mark, > > > > > > can you tell me what problem are you seeing with numtasks controller ? > > > > > > > > > ------------------------------------------------------- > > > SF email is sponsored by - The IT Product Guide > > > Read honest & candid reviews on hundreds of IT Products from real users. > > > Discover which products truly live up to the hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > > ckrm-tech mailing list > > > https://lists.sourceforge.net/lists/listinfo/ckrm-tech > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > ckrm-tech mailing list > > https://lists.sourceforge.net/lists/listinfo/ckrm-tech > -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Marc E. F. <mef@CS.Princeton.EDU> - 2005-04-12 19:49:19
|
Chandra, Eyeballing the code I cannot figure out what might be causing the problem we are observing. Specifically, all code incrementing or decrementing the cur_cnt_alloc is unchanged. Mostly what seems to have been added is the forkrate support. Any way, we see the numtasks_put_ref: Trying to decrement counter below 0 for a while and then after a day or so of uptime we can no longer fork. So maybe the bug really has to do with the forkrate support rather than the above printk. Is the forkrate support on by default? Marc > -----Original Message----- > From: ckr...@li... > [mailto:ckr...@li...]On Behalf Of Marc E. > Fiuczynski > Sent: Monday, April 11, 2005 11:12 PM > To: Chandra Seetharaman; ckr...@li... > Subject: RE: [ckrm-tech] ckrm cpu controller problems on laptop suspend > > > Chandra, > > We are seeing a number of these messages: > > numtasks_put_ref: Trying to decrement counter below 0 > > We did not see them before with the E16 version of the numtask controller. > > Marc > > > -----Original Message----- > > From: ckr...@li... > > [mailto:ckr...@li...]On Behalf Of Chandra > > Seetharaman > > Sent: Monday, April 11, 2005 3:20 PM > > To: ckr...@li... > > Subject: Re: [ckrm-tech] ckrm cpu controller problems on laptop suspend > > > > > > On Mon, Apr 11, 2005 at 02:38:32PM -0400, Marc E. Fiuczynski wrote: > > > Hi Shailabh, > > > > > > Doing a cvs upgrade will give you a kernel that has exhibits > > this problem. > > > > > > It also exhibits a separate numtasks problem that started to > > appear after I > > > upgraded to the E17 version of that controller, which I am > > debugging right > > > now. > > > > Mark, > > > > can you tell me what problem are you seeing with numtasks controller ? > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > ckrm-tech mailing list > > https://lists.sourceforge.net/lists/listinfo/ckrm-tech > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > ckrm-tech mailing list > https://lists.sourceforge.net/lists/listinfo/ckrm-tech |
From: Gerrit H. <gh...@us...> - 2005-04-12 17:58:24
|
On Tue, 12 Apr 2005 10:05:01 PDT, Chandra Seetharaman wrote: > On Tue, Apr 12, 2005 at 10:03:17AM -0700, Gerrit Huizenga wrote: > > > > > > Do you have any sugesstions for making the rbce_info.h file disappear ? > > > Since we can't carry man page and putting this info in Documentation > > > directory is not enough as the Documentation directory is not always > > > available to the user(It is sufficient for the other files as their > > > syntax is available in the corresponding files itself, which is not > > > the case with RBCE files). > > > > Well, if we wrap up the tools that the Bull folks are working on into > > a ckrm user level package, putting this documentation there would be > > This will be available only if one uses the user level tools, which is not > mandatory to use the interface. The other option is to start creating a HOWTO on CKRM. That probably gives you the best of several worlds. The HOWTO's on http://www.tldp.org/ are usually all wrapped up with all distros and provide an easy way to access the info. So, documenting in all 3 places is probably good: linux/Documentation/ckrm/*, tldp.org, and man page in the user level package. gerrit |
From: Chandra S. <sek...@us...> - 2005-04-12 17:12:39
|
On Tue, Apr 12, 2005 at 10:03:17AM -0700, Gerrit Huizenga wrote: > > > > Do you have any sugesstions for making the rbce_info.h file disappear ? > > Since we can't carry man page and putting this info in Documentation > > directory is not enough as the Documentation directory is not always > > available to the user(It is sufficient for the other files as their > > syntax is available in the corresponding files itself, which is not > > the case with RBCE files). > > Well, if we wrap up the tools that the Bull folks are working on into > a ckrm user level package, putting this documentation there would be This will be available only if one uses the user level tools, which is not mandatory to use the interface. > ideal (in man page format). Also, using the Documentation directory > with a file in the ckrm directory on RBCE Usage would be another As I mentioned, this also has shortcomings... Anyways, I will just move it to the Docuemntation directory. > partial solution. Using both solutions sounds like the right approach > to me. > > gerrit -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |
From: Nishanth A. <na...@us...> - 2005-04-12 17:10:14
|
On Tue, Apr 12, 2005 at 12:27:20PM -0400, Shailabh Nagar wrote: > Nishanth Aravamudan wrote: > >Hello, > > > >A word of warning, this e-mail is going to be long. Unlike than my > >previous (admittedly somewhat coarse) attempt to provide benchmark > >results, I am going to try and consolidate the data into one e-mail. > > > >These results represent running the following benchmarks on a PPC64 > >machine (8-way with 64GB of RAM). To make the table somewhat less wide, > >the following convention has been adopted: > > > >1) == 2.6.12-rc1 > >2) == 2.6.12-rc1 + current CKRM core patches + CONFIG_CKRM=n > >3) == 2.6.12-rc1 + current CKRM core patches + CONFIG_CKRM=y > >4) == 2.6.12-rc1 + current CKRM core & memrc patches + CONFIG_CKRM=n <snip> > >5) == 2.6.12-rc1 + current CKRM core & memrc patches + CONFIG_CKRM=y > > dbench -- 10 clients > > percentage of throughput relative to mainline > > > >---------------------------------------------------------------------- > >1) 100.00 > > > >2) 94.49 > > > Could you please provide a diffprofile between 1) & 2). > It seems really wierd that non-configured CKRM is still causing so much > of a drop (hope its not a case of mislabelling of 2 & 3). I triple-checked the labelling before sending :) And then checked it again just now. It is correct. Here is the diffprofile: 1813 2.8% .default_idle 905 95.2% .ext3_try_to_allocate_with_rsv 572 98.8% .start_this_handle 399 45.0% .ext3_test_allocatable 241 45.6% .bitmap_search_next_usable_block 208 11.0% .do_get_write_access 193 80.8% .ext3_discard_reservation 98 6.1% .journal_dirty_metadata 91 9.2% .journal_put_journal_head 87 5.3% .__copy_tofrom_user 73 13.2% .journal_stop 65 4.3% .journal_add_journal_head 65 10.5% .__find_get_block 54 27.3% .ext3_try_to_allocate 54 12.3% .journal_invalidatepage 44 36.1% .journal_get_undo_access 36 46.8% .kmem_cache_alloc 35 9.8% ._atomic_dec_and_lock 33 9.6% .unlock_buffer 31 7.3% .__brelse 28 7.3% .ext3_mark_iloc_dirty 25 16.1% .schedule 24 19.0% .ext3_free_blocks_sb 20 18.5% .path_lookup 20 14.8% .ext3_get_block_handle 19 12.7% .find_next_zero_le_bit 18 29.0% .mark_page_accessed 17 22.1% .__block_prepare_write 16 14.5% .release_pages 16 76.2% .fget 16 30.2% .create_empty_buffers 16 133.3% .flush_dcache_page 15 10.1% .__wait_on_bit_lock 15 15.6% .do_generic_mapping_read 14 53.8% .truncate_inode_pages 14 17.9% .link_path_walk 14 60.9% .scsi_request_fn 13 118.2% .ext3_readdir 12 34.3% .__block_commit_write 12 41.4% .free_hot_cold_page 11 137.5% .alloc_buffer_head 10 500.0% .radix_tree_preload 10 111.1% .__ext3_journal_stop 10 45.5% .fd_install 10 25.0% .journal_commit_transaction 8 16.0% .__wake_up_bit 8 88.9% .journal_get_write_access 8 800.0% .ext3_release_file 8 36.4% .sym53c8xx_intr 8 100.0% .dentry_open 8 21.6% .ext3_ordered_commit_write 7 50.0% .sys_close 7 38.9% .ext3_new_inode 7 350.0% .vfs_unlink 7 10.9% .add_to_page_cache 6 13.6% .__do_page_cache_readahead 6 54.5% .ext3_get_inode_loc 6 31.6% .__mod_page_state 6 120.0% .ext3_getblk -6 -85.7% .get_empty_filp -6 -60.0% .__generic_file_aio_read -6 -6.2% .kmem_cache_free -6 -42.9% .__alloc_pages -6 -19.4% .ext3_clear_blocks -7 -41.2% .ext3_orphan_add -7 -8.6% .__set_page_dirty_nobuffers -8 -19.5% .prepare_to_wait_exclusive -8 -66.7% .do_sync_read -8 -53.3% .io_schedule -9 -24.3% .current_fs_time -9 -47.4% .submit_bh -10 -11.5% system_call_common -10 -43.5% .get_write_access -10 -19.6% .__journal_file_buffer -10 -22.7% .ll_rw_block -10 -47.6% .memcpy -10 -21.3% .__find_get_block_slow -11 -68.8% .filldir64 -11 -18.3% .ext3_get_group_desc -11 -34.4% .__getblk -11 -15.9% .ext3_new_block -12 -9.4% .test_clear_page_dirty -12 -7.8% .find_lock_page -12 -24.5% .walk_page_buffers -12 -40.0% .__bread -12 -23.1% .dnotify_parent -13 -8.6% .__wake_up -13 -31.0% .buffered_rmqueue -13 -26.5% .path_release -15 -3.5% .find_get_page -15 -36.6% .wake_up_bit -17 -7.3% .__link_path_walk -33 -25.2% .ext3_journal_start_sb -39 -9.2% .__d_lookup -47 -20.2% .__ext3_get_inode_loc -56 -8.6% .journal_cancel_revoke -401 -48.4% .journal_dirty_data > If these results persist after multiple iterations (to remove any doubts > on statistical accuracy) and diffprofile doesn't offer many clues, it > would be helpful to isolate which patches/code is causing the > degradation by selectively applying the patches (the core kernel code > touched by the CKRM patches is relatively small and can be the first > place to look - all the code under kernel/ckrm shouldn't matter if CKRM > isn't configured). I certainly will try this. I have upped the iterations for all the benchmarks (unfortunately SPECjbb will take a while now :) ) and will wait to see those results before proceeding. <snip> > > tbench -- 8 clients > > percentage of throughput relative to mainline > > > >---------------------------------------------------------------------- > >1) 100.00 > > > >2) 95.45 > > Diffprofile between 1 & 2 useful here too. If they seem to match the > ones seen for dbench, it'll offer some clues. Here you go: 483 5.5% .default_idle 103 8.5% .tcp_v4_rcv 101 20.7% .__wake_up 93 27.8% .ip_queue_xmit 89 8.0% .schedule 66 29.6% .sock_def_readable 63 20.7% .__mod_timer 55 7.3% .ip_finish_output 44 55.7% .ip_output 40 48.2% .copy_from_user 40 12.5% .tcp_rcv_established 36 6.9% .fget 32 39.5% .sockfd_lookup 29 2.9% .__copy_tofrom_user 25 4.0% .process_backlog 24 14.0% .net_rx_action 22 169.2% system_call 21 35.0% .sock_sendmsg 19 3.9% .fput 19 15.2% .sock_recvmsg 15 3.4% .__kfree_skb 13 3.3% .release_sock 12 7.5% .ip_local_deliver 10 11.5% .inet_sendmsg 10 20.4% .do_softirq 10 7.2% .loopback_xmit 9 15.5% .tcp_send_delayed_ack 8 1.5% .netif_rx 7 7.9% .kfree 6 10.5% .skb_copy_datagram_iovec 6 5.3% .kmem_cache_alloc 6 300.0% syscall_error_cont 6 31.6% .csum_tcpudp_magic 6 85.7% .sys_send 6 40.0% .sched_clock -6 -12.8% .copy_to_user -6 -10.0% .tcp_event_data_recv -7 -15.6% .__tcp_ack_snd_check -7 -18.9% .sys_sendto -7 -4.1% .sys_recvfrom -8 -2.7% .dev_queue_xmit -8 -7.3% .ip_rcv -8 -22.9% .profile_hit -9 -16.7% .memcpy_toiovec -9 -36.0% .__alloc_pages -9 -3.5% .sock_wfree -9 -30.0% .eth_type_trans -9 -25.0% .sk_reset_timer -11 -10.4% .netif_receive_skb -11 -5.3% .tcp_ack -12 -9.4% .tcp_write_xmit -13 -8.8% .kmem_cache_free -14 -7.9% .prepare_to_wait -15 -5.8% .tcp_recvmsg -15 -57.7% .schedule_timeout -16 -10.7% .skb_clone -18 -11.0% .cleanup_rbuf -20 -26.7% .memcpy -20 -69.0% syscall_exit_trace_cont -20 -15.5% .__kmalloc -22 -25.6% .ip_fast_csum -23 -44.2% .alloc_skb -27 -96.4% ._read_unlock_bh -30 -8.1% .local_bh_enable -31 -5.5% .skb_release_data -36 -17.9% .__page_cache_release -41 -7.2% .tcp_sendmsg -51 -32.5% .mod_timer <snip> > >I have profiler output for all runs in all benchmarks, if anyone cares > >to see what may have caused certain runs to behave as they did, I can do > >a diffprofile and mail the results. > > > >I am still not satisfied with some of the runs being statistically > >valid, so I am going to rerun all of them at 20 iterations per > >benchmark, perhaps multiple times and do some gnuplotting to see what > >the values are doing. That will take a while, though, but I'll keep > >everyone posted. > > Thanks for doing this so systematically. I should thank Dave Hansen for his help & guidance in getting clean & useful results. Thanks, Nish |
From: Nishanth A. <na...@us...> - 2005-04-12 17:07:17
|
On Fri, Apr 08, 2005 at 02:59:03PM -0400, Shailabh Nagar wrote: > > If you can give > >me a good way to automatically create all the classes, I would be happy > >to try, though. > > > i=0 > while [ $i -le 1000 ] > do > let i=$i+1 > mkdir /rcfs/taskclass/$i > sleep 1 > done > > Should work without the sleep too but I got a barf on another kernel > variant I'm using. > > It might be interesting to monitor meminfo/slabinfo before and after. I am running some tests on the ppc64 machine with 100 taskclasses created before the benchmark. I am not going to run it on the NUMA-Q, as the memory controller has issues on NUMA and I'd like to be able to compare the two. Thanks, Nish |