From: Pavel Butsykin <pbutsykin@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com,
stefanha@redhat.com, den@openvz.org, jsnow@redhat.com,
eblake@redhat.com, famz@redhat.com
Subject: Re: [Qemu-devel] [PATCH RFC v2 09/22] block/pcache: separation AIOCB on requests
Date: Thu, 8 Sep 2016 18:47:13 +0300 [thread overview]
Message-ID: <57D18801.7090801@virtuozzo.com> (raw)
In-Reply-To: <20160902091036.GC4513@noname.redhat.com>
On 02.09.2016 12:10, Kevin Wolf wrote:
> Am 29.08.2016 um 19:10 hat Pavel Butsykin geschrieben:
>> for case when the cache partially covers request we are part of the request
>> is filled from the cache, and the other part request from disk. Also add
>> reference counting for nodes, as way to maintain multithreading.
>>
>> There is still no full synchronization in multithreaded mode.
>>
>> Signed-off-by: Pavel Butsykin <pbutsykin@virtuozzo.com>
>> ---
>> block/pcache.c | 169 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
>> 1 file changed, 155 insertions(+), 14 deletions(-)
>>
>> diff --git a/block/pcache.c b/block/pcache.c
>> index 28bd056..6114289 100644
>> --- a/block/pcache.c
>> +++ b/block/pcache.c
>> @@ -58,7 +58,10 @@ typedef struct BlockNode {
>> typedef struct PCNode {
>> BlockNode cm;
>>
>> + uint32_t status;
>
> I guess this is NODE_*_STATUS. Make it a named enum then instead of
> uint32_t so that it's obvious what this field means.
OK
>> + uint32_t ref;
>> uint8_t *data;
>> + CoMutex lock;
>> } PCNode;
>>
>> typedef struct ReqStor {
>> @@ -95,9 +98,23 @@ typedef struct PrefCacheAIOCB {
>> uint64_t sector_num;
>> uint32_t nb_sectors;
>> int aio_type;
>> + struct {
>> + QTAILQ_HEAD(req_head, PrefCachePartReq) list;
>> + CoMutex lock;
>> + } requests;
>> int ret;
>> } PrefCacheAIOCB;
>>
>> +typedef struct PrefCachePartReq {
>> + uint64_t sector_num;
>> + uint32_t nb_sectors;
>
> Should be byte-based, like everything.
>
>> + QEMUIOVector qiov;
>> + PCNode *node;
>> + PrefCacheAIOCB *acb;
>> + QTAILQ_ENTRY(PrefCachePartReq) entry;
>> +} PrefCachePartReq;
>> +
>> static const AIOCBInfo pcache_aiocb_info = {
>> .aiocb_size = sizeof(PrefCacheAIOCB),
>> };
>> @@ -126,8 +143,39 @@ static QemuOptsList runtime_opts = {
>> #define MB_BITS 20
>> #define PCACHE_DEFAULT_CACHE_SIZE (4 << MB_BITS)
>>
>> +enum {
>> + NODE_SUCCESS_STATUS = 0,
>> + NODE_WAIT_STATUS = 1,
>> + NODE_REMOVE_STATUS = 2,
>> + NODE_GHOST_STATUS = 3 /* only for debugging */
>
> NODE_DELETED_STATUS?
Yes :)
>> +};
>> +
>> #define PCNODE(_n) ((PCNode *)(_n))
>>
>> +static inline void pcache_node_unref(PCNode *node)
>> +{
>> + assert(node->status == NODE_SUCCESS_STATUS ||
>> + node->status == NODE_REMOVE_STATUS);
>> +
>> + if (atomic_fetch_dec(&node->ref) == 0) {
>
> Atomics imply concurrency, which we don't have.
>
>> + assert(node->status == NODE_REMOVE_STATUS);
>> +
>> + node->status = NODE_GHOST_STATUS;
>> + g_free(node->data);
>> + g_slice_free1(sizeof(*node), node);
>
> When you switch to plain g_malloc(), this needs to be updated.
>
>> + }
>> +}
>> +
>> +static inline PCNode *pcache_node_ref(PCNode *node)
>> +{
>> + assert(node->status == NODE_SUCCESS_STATUS ||
>> + node->status == NODE_WAIT_STATUS);
>> + assert(atomic_read(&node->ref) == 0);/* XXX: only for sequential requests */
>> + atomic_inc(&node->ref);
>
> Do you expect concurrent accesses or not? Because if you don't, there is
> no need for atomics, but if you do, this is buggy because each of the
> lines is atomic for itself, but the assertion isn't atomic with the
> refcount increment.
Well, about concurrent accesses, we've already figured out.
> A ref() function that can take only a single reference feels odd anyway
> and this restriction seems to be lifted later. Why have it here?
No, this is a temporary assert(). In fact, it is not necessary, but the
assert helps to check the correct functioning on the current patch,
because not yet implemented reading of nodes and rescheduling requests.
>> +
>> + return node;
>> +}
>
> Kevin
>
next prev parent reply other threads:[~2016-09-08 16:20 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 17:09 [Qemu-devel] [PATCH RFC v2 00/22] I/O prefetch cache Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 01/22] block/pcache: empty pcache driver filter Pavel Butsykin
2016-09-01 14:31 ` Kevin Wolf
2016-09-06 15:20 ` Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 02/22] block/pcache: add own AIOCB block Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 03/22] util/rbtree: add rbtree from linux kernel Pavel Butsykin
2016-09-01 14:37 ` Kevin Wolf
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 04/22] block/pcache: add pcache debug build Pavel Butsykin
2016-09-08 15:11 ` Eric Blake
2016-09-08 15:49 ` Pavel Butsykin
2016-09-08 16:05 ` Pavel Butsykin
2016-09-08 18:42 ` Eric Blake
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 05/22] block/pcache: add aio requests into cache Pavel Butsykin
2016-09-01 15:28 ` Kevin Wolf
2016-09-06 16:54 ` Pavel Butsykin
2016-09-06 17:07 ` Kevin Wolf
2016-09-07 16:21 ` Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 06/22] block/pcache: restrict cache size Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 07/22] block/pcache: introduce LRU as method of memory Pavel Butsykin
2016-09-02 8:49 ` Kevin Wolf
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 08/22] block/pcache: implement pickup parts of the cache Pavel Butsykin
2016-09-02 8:59 ` Kevin Wolf
2016-09-08 12:29 ` Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 09/22] block/pcache: separation AIOCB on requests Pavel Butsykin
2016-09-02 9:10 ` Kevin Wolf
2016-09-08 15:47 ` Pavel Butsykin [this message]
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 10/22] block/pcache: add check node leak Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 11/22] add QEMU style defines for __sync_add_and_fetch Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 12/22] block/pcache: implement read cache to qiov and drop node during aio write Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 13/22] block/pcache: add generic request complete Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 14/22] block/pcache: add support for rescheduling requests Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 15/22] block/pcache: simple readahead one chunk forward Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 16/22] block/pcache: pcache readahead node around Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 17/22] block/pcache: skip readahead for non-sequential requests Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 18/22] block/pcache: add pcache skip large aio read Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 19/22] block/pcache: add pcache node assert Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 20/22] block/pcache: implement pcache error handling of aio cb Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 21/22] block/pcache: add write through node Pavel Butsykin
2016-08-29 17:10 ` [Qemu-devel] [PATCH RFC v2 22/22] block/pcache: drop used pcache node Pavel Butsykin
2016-09-01 14:17 ` [Qemu-devel] [PATCH RFC v2 00/22] I/O prefetch cache Kevin Wolf
2016-09-06 12:36 ` Pavel Butsykin
2016-09-01 15:26 ` Avi Kivity
2016-09-06 12:40 ` Pavel Butsykin
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=57D18801.7090801@virtuozzo.com \
--to=pbutsykin@virtuozzo.com \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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.