qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 08/22] block/pcache: implement pickup parts of the cache
Date: Thu, 8 Sep 2016 15:29:22 +0300	[thread overview]
Message-ID: <57D159A2.4000702@virtuozzo.com> (raw)
In-Reply-To: <20160902085946.GB4513@noname.redhat.com>

On 02.09.2016 11:59, Kevin Wolf wrote:
> Am 29.08.2016 um 19:10 hat Pavel Butsykin geschrieben:
>> Implementation of obtaining fragments of the cache belonging to one area
>> of request. This will allow to handle the case when a request is partially
>> hits the cache.
>>
>> Signed-off-by: Pavel Butsykin <pbutsykin@virtuozzo.com>
>
>> +static void pcache_pickup_parts_of_cache(PrefCacheAIOCB *acb, PCNode *node,
>> +                                         uint64_t num, uint32_t size)
>> +{
>> +    uint32_t up_size;
>> +
>> +    do {
>> +        if (num < node->cm.sector_num) {
>> +            PCNode *new_node;
>> +            RbNodeKey lc_key = {
>> +                .num = num,
>> +                .size = node->cm.sector_num - num,
>> +            };
>> +            up_size = lc_key.size;
>> +
>> +            if (!pcache_node_find_and_create(acb, &lc_key, &new_node)) {
>> +                node = new_node;
>> +                continue;
>> +            }
>
> We're creating additional nodes here; and we need them because they have
> their own status. But once the read has completed, wouldn't it make
> sense to merge all adjacent nodes in NODE_SUCCESS_STATUS?

This can be done, but first we need to think, worth it or not. If we
merge nodes, the tree will have less nodes, the search will be faster,
that's good. But we will have to re-allocate memory, as well as the
merging could lead to the formation of larger nodes, and it's not very
good for the displacement, because it increases the chance of
displacement of unread areas of the cache memory.

I think we do not need to cache missing memory, because it is contrary
to the read-ahead policy. (read the area of the disk once will not be
read again) Also, considering the 22nd patch(
[PATCH RFC v2 22/22] block/pcache: drop used pcache node), it just
makes no sense to move the missing pieces of data in the cache memory.

> Kevin
>

  reply	other threads:[~2016-09-08 21:04 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 [this message]
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
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=57D159A2.4000702@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 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).