From: "Maíra Canal" <mcanal@igalia.com>
To: Iago Toral <itoral@igalia.com>, Melissa Wen <mwen@igalia.com>,
Tvrtko Ursulin <tursulin@igalia.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, kernel-dev@igalia.com,
Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Subject: Re: [PATCH v4 7/8] drm/v3d: Use gemfs/THP in BO creation if available
Date: Mon, 29 Apr 2024 13:52:50 -0300 [thread overview]
Message-ID: <0b64735c-6dab-42f0-92c5-57b7b8dfaf47@igalia.com> (raw)
In-Reply-To: <0a966cc891b388133013b37820b7e0e7d982654c.camel@igalia.com>
Hi Iago,
On 4/29/24 02:22, Iago Toral wrote:
> Hi Maíra,
>
> a question below:
>
> El dom, 28-04-2024 a las 09:40 -0300, Maíra Canal escribió:
>> Although Big/Super Pages could appear naturally, it would be quite
>> hard
>> to have 1MB or 64KB allocated contiguously naturally. Therefore, we
>> can
>> force the creation of large pages allocated contiguously by using a
>> mountpoint with "huge=within_size" enabled.
>>
>> Therefore, as V3D has a mountpoint with "huge=within_size" (if user
>> has
>> THP enabled), use this mountpoint for BO creation if available. This
>> will allow us to create large pages allocated contiguously and make
>> use
>> of Big/Super Pages.
>>
>> Signed-off-by: Maíra Canal <mcanal@igalia.com>
>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
>> ---
>>
>
> (...)
>
>> @@ -130,10 +140,17 @@ struct v3d_bo *v3d_bo_create(struct drm_device
>> *dev, struct drm_file *file_priv,
>> size_t unaligned_size)
>> {
>> struct drm_gem_shmem_object *shmem_obj;
>> + struct v3d_dev *v3d = to_v3d_dev(dev);
>> struct v3d_bo *bo;
>> int ret;
>>
>> - shmem_obj = drm_gem_shmem_create(dev, unaligned_size);
>> + /* Let the user opt out of allocating the BOs with THP */
>> + if (v3d->gemfs)
>> + shmem_obj = drm_gem_shmem_create_with_mnt(dev,
>> unaligned_size,
>> + v3d-
>>> gemfs);
>> + else
>> + shmem_obj = drm_gem_shmem_create(dev,
>> unaligned_size);
>> +
>> if (IS_ERR(shmem_obj))
>> return ERR_CAST(shmem_obj);
>> bo = to_v3d_bo(&shmem_obj->base);
>
>
> if I read this correctly when we have THP we always allocate with that,
> Even objects that are smaller than 64KB. I was wondering if there is
> any benefit/downside to this or if the behavior for small allocations
> is the same we had without the new mount point.
I'm assuming that your concern is related to memory pressure and memory
fragmentation.
As we are using `huge=within_size`, we only allocate a huge page if it
will be fully within `i_size`. When using `huge=within_size`, we can
optimize the performance for smaller files without forcing larger files
to also use huge pages. I don't understand `huge=within_size` in full
details, but it is possible to check that it is able to avoid the system
(even the RPi) to go OOM. Although it is slightly less performant than
`huge=always` (used in v1), I believe it is more ideal for a system such
as the RPi due to the memory requirements.
Best Regards,
- Maíra
>
> Iago
next prev parent reply other threads:[~2024-04-29 16:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-28 12:40 [PATCH v4 0/8] drm/v3d: Enable Big and Super Pages Maíra Canal
2024-04-28 12:40 ` [PATCH v4 1/8] drm/v3d: Fix return if scheduler initialization fails Maíra Canal
2024-04-28 12:40 ` [PATCH v4 2/8] drm/gem: Create a drm_gem_object_init_with_mnt() function Maíra Canal
2024-04-28 12:40 ` [PATCH v4 3/8] drm/v3d: Introduce gemfs Maíra Canal
2024-04-28 12:40 ` [PATCH v4 4/8] drm/gem: Create shmem GEM object in a given mountpoint Maíra Canal
2024-04-28 12:40 ` [PATCH v4 5/8] drm/v3d: Reduce the alignment of the node allocation Maíra Canal
2024-04-28 12:40 ` [PATCH v4 6/8] drm/v3d: Support Big/Super Pages when writing out PTEs Maíra Canal
2024-04-28 12:40 ` [PATCH v4 7/8] drm/v3d: Use gemfs/THP in BO creation if available Maíra Canal
2024-04-29 5:22 ` Iago Toral
2024-04-29 16:52 ` Maíra Canal [this message]
2024-04-28 12:40 ` [PATCH v4 8/8] drm/v3d: Add modparam for turning off Big/Super Pages Maíra Canal
2024-04-29 8:24 ` Tvrtko Ursulin
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=0b64735c-6dab-42f0-92c5-57b7b8dfaf47@igalia.com \
--to=mcanal@igalia.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=itoral@igalia.com \
--cc=kernel-dev@igalia.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=mwen@igalia.com \
--cc=tursulin@igalia.com \
--cc=tvrtko.ursulin@igalia.com \
--cc=tzimmermann@suse.de \
/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.