On 5/17/24 14:36, Hannes Reinecke wrote:
On 5/16/24 17:02, Pankaj Raghav (Samsung) wrote:
On Wed, May 15, 2024 at 07:03:20PM +0100, Matthew Wilcox wrote:
On Wed, May 15, 2024 at 03:59:43PM +0000, Pankaj Raghav (Samsung) wrote:
static int __init iomap_init(void)
{
+ void *addr = kzalloc(16 * PAGE_SIZE, GFP_KERNEL);
Don't use XFS coding style outside XFS.
kzalloc() does not guarantee page alignment much less alignment to
a folio. It happens to work today, but that is an implementation
artefact.
+
+ if (!addr)
+ return -ENOMEM;
+
+ zero_fsb_folio = virt_to_folio(addr);
We also don't guarantee that calling kzalloc() gives you a virtual
address that can be converted to a folio. You need to allocate a folio
to be sure that you get a folio.
Of course, you don't actually need a folio. You don't need any of the
folio metadata and can just use raw pages.
+ /*
+ * The zero folio used is 64k.
+ */
+ WARN_ON_ONCE(len > (16 * PAGE_SIZE));
PAGE_SIZE is not necessarily 4KiB.
+ bio = iomap_dio_alloc_bio(iter, dio, BIO_MAX_VECS,
+ REQ_OP_WRITE | REQ_SYNC | REQ_IDLE);
The point was that we now only need one biovec, not MAX.
Thanks for the comments. I think it all makes sense:
diff --git a/fs/internal.h b/fs/internal.h
index 7ca738904e34..e152b77a77e4 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -35,6 +35,14 @@ static inline void bdev_cache_init(void)
int __block_write_begin_int(struct folio *folio, loff_t pos,
unsigned len,
get_block_t *get_block, const struct iomap *iomap);
+/*
+ * iomap/buffered-io.c
+ */
+
+#define ZERO_FSB_SIZE (65536)
+#define ZERO_FSB_ORDER (get_order(ZERO_FSB_SIZE))
+extern struct page *zero_fs_block;
+
/*
* char_dev.c
*/
But why?
We already have a perfectly fine hugepage zero page in huge_memory.c.
Shouldn't we rather export that one and use it?
(Actually I have some patches for doing so...)
We might allocate folios
Bah. Hit 'enter' too soon.
We might allocate a zero folio as a fallback if the huge zero page is
not available, but first we should try to use that.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
