All of lore.kernel.org
 help / color / mirror / Atom feed
From: Weikuan Yu <weikuan.yu@gmail.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] 2 primitives for the NRS
Date: Fri, 04 Jan 2008 12:00:30 -0500	[thread overview]
Message-ID: <477E662E.30803@gmail.com> (raw)
In-Reply-To: <00d501c84ed6$e4fb2010$0281a8c0@ebpc>

Hi,

I am trying to plug in an I/O request scheduler into OSS before read/write 
requests get dispatched to the obdfilter. What I am using is hashed bins 
with a basic rb tree, assuming it would be fairly reasonable to handle the 
number of I/O requests that can reach an OSS. My interface calls are very 
similar to yours, except the lack of plug-in comparison. I would not have 
more to suggest on this. But I do have a couple of questions to check for 
possible thoughts if you have.

(1) How are you going to order the requests, say the read/write ones? I 
assume you made it flexible with a plug-in compare(). Would the order of the 
I/O requests based on object ID have some relevance to their locality on the 
disks? I was assuming at least the requests can get smoothed out with the 
objID ordering.

(2) Have you checked the overhead when there are many concurrent threads 
competing for the locks associated with your heap? The performance impact 
thereof?

(3) Do you anticipate to merge the requests in any way, or possibly batch 
execute them?

--Weikuan


Eric Barton wrote:
> What the NRS (network request scheduler) really needs is something
> that can order 10**[4-6] RPC requests incredibly efficiently - any
> overhead just eats into server efficiency and we already swamp a
> server with simple pings at ~30-40,000 RPCs per second.  I've
> implemented a heap which is already looking good at managing
> collections of 1,000,000+ objects with nearly sub-microsecond
> insert+ordered_remove overhead.
> 
> Here is the API, which also introduces a sparse 1D array suitable for
> use in the kernel.  The binary heap uses it as space and cache
> efficient means of tree walking.
> 
> Any suggestions for improving the API appreciated...
> 
> #ifndef __LIBCFS_BHEAP_H__
> #define __LIBCFS_BHEAP_H__
> 
> /* Auto-array 
>  * A sparse 1D contiguous array of pointers which uses single, double and
>  * triple indirection maps and avoids allocating large contiguous memory.
>  *
>  * FIXME: CAA_SHIFT should be defined automatically so that 
>  * (CAA_SIZE == CFS_PAGE_SIZE/sizeof(void *))
>  */
> 
> #define CAA_SHIFT  10
> #define CAA_SIZE   (1 << CAA_SHIFT)             /* # ptrs per level */
> #define CAA_MASK   (CAA_SIZE - 1)
> #define CAA_NOB    (CAA_SIZE * sizeof(void *))
> 
> typedef struct
> {
>         void         ****aa_3d;                 /* Triple indirect */
>         void          ***aa_2d;                 /* double indirect */
>         void           **aa_1d;                 /* single indirect */
> } cfs_autoarray_t;
> 
> void   cfs_aa_init(cfs_autoarray_t *aa);         /* setup */
> void   cfs_aa_fini(cfs_autoarray_t *aa);         /* free all allocated mem */
> 
> /* effectively &aa[idx] but you MUST know &aa[idx] exists */
> void **cfs_aa_index(cfs_autoarray_t *aa, unsigned int idx);
> 
> /* effectively &aa[idx] - return NULL if &aa[idx] doesn't exist and 'grow' is
>  * FALSE */
> void **cfs_aa_lookup(cfs_autoarray_t *aa, unsigned int idx, int grow);
> 
> 
> /* Binary heap
>  * 
>  * Supports insertion and ordered removal of members sorted by the given total
>  * order ('compare')
>  */
> 
> typedef struct
> {
>         cfs_autoarray_t  cbh_members;
>         unsigned int     cbh_size;
>         unsigned int     cbh_maxsize;
>         int            (*cbh_compare)(void *a, void *b);
> } cfs_binheap_t;
> 
> void  cfs_binheap_init(cfs_binheap_t *h, int (*compare)(void *a, void *b));
> void  cfs_binheap_fini(cfs_binheap_t *h);
> int   cfs_binheap_size(cfs_binheap_t *h);
> int   cfs_binheap_insert(cfs_binheap_t *h, void *e);
> void *cfs_binheap_remove_root(cfs_binheap_t *h);
> 
> #endif /* __LIBCFS_BHEAP_H__ */
> 
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at clusterfs.com
> https://mail.clusterfs.com/mailman/listinfo/lustre-devel
> 

  reply	other threads:[~2008-01-04 17:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-04 13:37 [Lustre-devel] 2 primitives for the NRS Eric Barton
2008-01-04 17:00 ` Weikuan Yu [this message]
2008-01-04 18:19   ` Eric Barton
2008-01-04 17:40 ` Lee Ward
2008-01-04 17:51   ` Eric Barton
2008-01-04 18:36   ` Eric Barton
2008-01-05  0:36     ` Lee Ward
2008-01-05 12:19 ` Alex Lyashkov

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=477E662E.30803@gmail.com \
    --to=weikuan.yu@gmail.com \
    --cc=lustre-devel@lists.lustre.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.