All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Qu Wenruo <wqu@suse.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 6/8] btrfs: store a kernel virtual address in struct sector_ptr
Date: Thu, 10 Apr 2025 07:34:13 +0200	[thread overview]
Message-ID: <20250410053413.GC30044@lst.de> (raw)
In-Reply-To: <0b3a6b18-ab19-4997-86dc-fd269b7b61da@suse.com>

On Thu, Apr 10, 2025 at 08:04:25AM +0930, Qu Wenruo wrote:
> 在 2025/4/9 20:40, Christoph Hellwig 写道:
>> All data pointed to by struct sector_ptr is non-highmem kernel memory.
>> Simplify the code by using a void pointer instead of a page + offset
>> pair and dropping all the kmap calls.
>
> But the higher level bio from btrfs filemaps can have highmem pages.
>
> That's why we keep the kmap/kunmap.

Where do filemap pages come into the raid code?   As far as I can see
they are always copied, and the memory is only allocated in the raid
code.  As seen in this code we have two direct allocations that I
convered to __get_free_page, and one case that uses the bulk page
allocator where I use page_address.  Or did I miss something?

> Or is there a way to set the filemap to no use any highmem pages?

You can restrict the allocation of a mapping to avoid highmem using
mapping_set_gfp_mask().  But that would not help with direct I/O IFF
user pages came into this code.


  reply	other threads:[~2025-04-10  5:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09 11:10 RFC: (almost) stop poking into bvec internals in btrfs Christoph Hellwig
2025-04-09 11:10 ` [PATCH 1/8] btrfs: remove the alignment checks in end_bbio_data_read Christoph Hellwig
2025-04-09 22:13   ` Qu Wenruo
2025-04-10  5:30     ` Christoph Hellwig
2025-04-10  5:39       ` Qu Wenruo
2025-04-09 11:10 ` [PATCH 2/8] btrfs: track the next file offset in struct btrfs_bio_ctrl Christoph Hellwig
2025-04-09 22:15   ` Qu Wenruo
2025-04-09 11:10 ` [PATCH 3/8] btrfs: pass a physical address to btrfs_repair_io_failure Christoph Hellwig
2025-04-09 22:19   ` Qu Wenruo
2025-04-10  5:31     ` Christoph Hellwig
2025-04-10  6:06   ` Johannes Thumshirn
2025-04-10  6:17     ` hch
2025-04-09 11:10 ` [PATCH 4/8] btrfs: move kmapping out of btrfs_check_sector_csum Christoph Hellwig
2025-04-10  6:16   ` Johannes Thumshirn
2025-04-16  4:51   ` Qu Wenruo
2025-04-09 11:10 ` [PATCH 5/8] btrfs: simplify bvec iteration in index_one_bio Christoph Hellwig
2025-04-18  2:09   ` Qu Wenruo
2025-04-09 11:10 ` [PATCH 6/8] btrfs: store a kernel virtual address in struct sector_ptr Christoph Hellwig
2025-04-09 22:34   ` Qu Wenruo
2025-04-10  5:34     ` Christoph Hellwig [this message]
2025-04-14  3:04       ` Qu Wenruo
2025-04-17 23:41         ` Qu Wenruo
2025-04-09 11:10 ` [PATCH 7/8] btrfs: refactor getting the address of a stripe sector Christoph Hellwig
2025-04-09 22:38   ` Qu Wenruo
2025-04-19  1:01   ` Qu Wenruo
2025-04-09 11:10 ` [PATCH 8/8] btrfs: use bvec_kmap_local in btrfs_decompress_buf2page Christoph Hellwig

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=20250410053413.GC30044@lst.de \
    --to=hch@lst.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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.