On Mon, 4 Apr 2011 14:44:40 +0300 Or Gerlitz <ogerlitz@xxxxxxxxxxxx> wrote: > FUJITA Tomonori wrote: > > On Wed, 30 Mar 2011 22:12:23 +0400 > > stepan.fedorov wrote: > > >> Thanks all for attension, but question remains open: what can we do, > >> to serve 1500-3000 LUNs from one node with no more then 24Gb of memory? > > > Maybe the following patch works for you. > > Yep, it looks something that has to do with the threads code consumes > about 10MB per thread... Stepan, you should be able to see that using > your script that allocates targets and measures the memory consumption > if applying the following trivial patch, I hope that either Tomo or > someone here will be able to address that soon > > > diff --git a/usr/bs_thread.h b/usr/bs_thread.h > > index d460032..3e3ba79 100644 > > --- a/usr/bs_thread.h > > +++ b/usr/bs_thread.h > > @@ -1,4 +1,4 @@ > > -#define NR_WORKER_THREADS 4 > > +#define NR_WORKER_THREADS 1 > > > > typedef void (request_func_t) (struct scsi_cmd *); > > Tomo, could you spare few words on the patch / approach you had in mind > to address that? I see that your patch would only call bs_thread_open > once, e.g if (!init), where today it is called once per LUN... also I > wasn't sure to follow why you've enlarged the number of threads from 4 > to 16, does this moves to global thread pool or alike? Yeah, this patch uses 16 global threads instead of creating 4 threads per lun. Needs some cleanups though. We had better adjust the number of threads dynamically. I think that the static approach is fine for now. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
