linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Corry <corryk@us.ibm.com>
To: Jens Axboe <axboe@suse.de>
Cc: evms-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] EVMS Release 1.2.0
Date: Tue, 1 Oct 2002 08:18:19 -0500	[thread overview]
Message-ID: <02100108181900.20800@boiler> (raw)
In-Reply-To: <20021001102043.GD20878@suse.de>

On Tuesday 01 October 2002 05:20, Jens Axboe wrote:
> On Mon, Sep 30 2002, Kevin Corry wrote:
> > The EVMS team is announcing the next stable release of the Enterprise
> > Volume Management System, which will eventually become EVMS 2.0. Package
> > 1.2.0 is now available for download at the project web site:
> > http://www.sf.net/projects/evms
>
> [evms.c]
>
> #ifndef CONFIG_SMP
> static spinlock_t evms_request_lock = SPIN_LOCK_UNLOCKED;
> #endif
>
> ...
>
> #ifdef CONFIG_SMP
>        blk_dev[EVMS_MAJOR].queue = evms_find_queue;
> #else
>        blk_init_queue(BLK_DEFAULT_QUEUE(EVMS_MAJOR),
>                       evms_do_request_fn, &evms_request_lock);
>        blk_queue_make_request(BLK_DEFAULT_QUEUE(EVMS_MAJOR),
>                               evms_make_request_fn);
> #endif
>
> ...
>
> #ifdef CONFIG_SMP
>        lv->request_lock = SPIN_LOCK_UNLOCKED;
>        blk_init_queue(&lv->request_queue,
>                       evms_do_request_fn,
>                       &lv->request_lock);
>        blk_queue_make_request(&lv->request_queue,
>                               evms_make_request_fn);
> #endif
>
> What the hell is that about?

The above code implements a single request queue for the EVMS driver on 
uniprocessor, and per-volume request queues on SMP. This was done quite some 
time ago (before 2.5), since we felt SMP was the only place where there was a 
performance advantage to having multiple queues (and thus using up all the 
extra memory on UP was wasteful). Since a lot of things have changed in 2.5 
(e.g. prempt), there might be performance advantages on UP now as well.

I was reading over the kernel Bitkeeper changelogs last night and noticed you 
made some changes to the loop driver to implement per-device queues. I talked 
this over with Mark and we decided that if this was the trend, we would 
switch to always using per-volume queues. If you take a look at our bitkeeper 
tree, you should see that change is already in. Unfortunately, this was after 
1.2.0 was released, so that change isn't available in the package I announced 
yesterday. But, the 2.5 code changes almost daily anyway, so I'm not too 
worried. And from looking over the Bitkeeper logs, it looks like there are 
more gendisk changes in 2.5.40 that may affect EVMS, so there will probably 
be additional changes today.

If you have any additional comments, please let us know.

-- 
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/

  reply	other threads:[~2002-10-01 13:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-30 22:01 [ANNOUNCE] EVMS Release 1.2.0 Kevin Corry
2002-10-01 10:20 ` Jens Axboe
2002-10-01 13:18   ` Kevin Corry [this message]
2002-10-01 20:13     ` Greg KH
2002-10-01 21:19       ` Kevin Corry
2002-10-01 22:17         ` Greg KH
2002-10-02 13:06           ` Kevin Corry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02100108181900.20800@boiler \
    --to=corryk@us.ibm.com \
    --cc=axboe@suse.de \
    --cc=evms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).