From: Dongsheng Yang <dongsheng.yang@linux.dev>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: mpatocka@redhat.com, agk@redhat.com, snitzer@kernel.org,
axboe@kernel.dk, hch@lst.de, dan.j.williams@intel.com,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev,
dm-devel@lists.linux.dev
Subject: Re: [PATCH v1 05/11] dm-pcache: add cache_segment
Date: Mon, 7 Jul 2025 14:24:27 +0800 [thread overview]
Message-ID: <09b2de99-8b59-4755-9296-a016d2670801@linux.dev> (raw)
In-Reply-To: <20250701155928.0000160a@huawei.com>
在 7/1/2025 10:59 PM, Jonathan Cameron 写道:
> On Tue, 24 Jun 2025 07:33:52 +0000
> Dongsheng Yang <dongsheng.yang@linux.dev> wrote:
>
>> Introduce *cache_segment.c*, the in-memory/on-disk glue that lets a
>> `struct pcache_cache` manage its array of data segments.
>>
>> * Metadata handling
>> - Loads the most-recent replica of both the segment-info block
>> (`struct pcache_segment_info`) and per-segment generation counter
>> (`struct pcache_cache_seg_gen`) using `pcache_meta_find_latest()`.
>> - Updates those structures atomically with CRC + sequence rollover,
>> writing alternately to the two metadata slots inside each segment.
>>
>> * Segment initialisation (`cache_seg_init`)
>> - Builds a `struct pcache_segment` pointing to the segment’s data
>> area, sets up locks, generation counters, and, when formatting a new
>> cache, zeroes the on-segment kset header.
>>
>>
>> +
>> + cache = cache_seg->cache;
>> + cache_seg_gen_increase(cache_seg);
>> +
>> + spin_lock(&cache->seg_map_lock);
>> + if (cache->cache_full)
>> + cache->cache_full = false;
> Perhaps just write cache->cache_full = false unconditionally?
> If there is a reason to not do the write, then add a comment here.
Hi Jonathan,
When the cache->cache_full is already false, we don't need to write
cache->cache_full with false.
Thanx
Dongsheng
>
>> + clear_bit(cache_seg->cache_seg_id, cache->seg_map);
>> + spin_unlock(&cache->seg_map_lock);
>> +
>> + pcache_defer_reqs_kick(CACHE_TO_PCACHE(cache));
>> + /* clean_work will clean the bad key in key_tree*/
>> + queue_work(cache_get_wq(cache), &cache->clean_work);
>> +}
next prev parent reply other threads:[~2025-07-07 6:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 7:33 [PATCH v1 00/11] dm-pcache – persistent-memory cache for block devices Dongsheng Yang
2025-06-24 7:33 ` [PATCH v1 01/11] dm-pcache: add pcache_internal.h Dongsheng Yang
2025-07-01 13:43 ` Jonathan Cameron
2025-06-24 7:33 ` [PATCH v1 02/11] dm-pcache: add backing device management Dongsheng Yang
2025-07-01 13:56 ` Jonathan Cameron
2025-07-07 6:25 ` Dongsheng Yang
2025-06-24 7:33 ` [PATCH v1 03/11] dm-pcache: add cache device Dongsheng Yang
2025-07-01 14:07 ` Jonathan Cameron
2025-06-24 7:33 ` [PATCH v1 04/11] dm-pcache: add segment layer Dongsheng Yang
2025-07-01 14:46 ` Jonathan Cameron
2025-07-07 6:24 ` Dongsheng Yang
2025-06-24 7:33 ` [PATCH v1 05/11] dm-pcache: add cache_segment Dongsheng Yang
2025-07-01 14:59 ` Jonathan Cameron
2025-07-07 6:24 ` Dongsheng Yang [this message]
2025-06-24 7:33 ` [PATCH v1 06/11] dm-pcache: add cache_writeback Dongsheng Yang
2025-06-24 7:33 ` [PATCH v1 07/11] dm-pcache: add cache_gc Dongsheng Yang
2025-06-24 7:33 ` [PATCH v1 08/11] dm-pcache: add cache_key Dongsheng Yang
2025-06-24 7:33 ` [PATCH v1 09/11] dm-pcache: add cache_req Dongsheng Yang
2025-06-24 7:33 ` [PATCH v1 10/11] dm-pcache: add cache core Dongsheng Yang
2025-06-24 7:33 ` [PATCH v1 11/11] dm-pcache: initial dm-pcache target Dongsheng Yang
2025-06-30 13:30 ` [PATCH v1 00/11] dm-pcache – persistent-memory cache for block devices Mikulas Patocka
2025-06-30 13:40 ` Dongsheng Yang
2025-06-30 14:16 ` Dongsheng Yang
2025-06-30 15:45 ` Mikulas Patocka
2025-06-30 16:30 ` Dongsheng Yang
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=09b2de99-8b59-4755-9296-a016d2670801@linux.dev \
--to=dongsheng.yang@linux.dev \
--cc=Jonathan.Cameron@huawei.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@intel.com \
--cc=dm-devel@lists.linux.dev \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=nvdimm@lists.linux.dev \
--cc=snitzer@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 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.