From: Matthew Auld <matthew.auld@intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t v5 11/15] lib/intel_allocator: treat default_alignment as the minimum
Date: Tue, 24 Oct 2023 18:16:26 +0100 [thread overview]
Message-ID: <8de4e1c7-d353-620d-6920-05c4e1328808@intel.com> (raw)
In-Reply-To: <20231024163949.v6gt7n6gprodvh7v@zkempczy-mobl2>
On 24/10/2023 17:39, Zbigniew Kempczyński wrote:
> On Fri, Oct 20, 2023 at 10:37:57AM +0100, Matthew Auld wrote:
>> If something overrides the default alignment, we should only apply the
>> alignment if it is larger than the default_alignment.
>>
>> v2 (Niranjana):
>> - Simplify slightly
>>
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
>> Cc: José Roberto de Souza <jose.souza@intel.com>
>> Cc: Pallavi Mishra <pallavi.mishra@intel.com>
>> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
>> ---
>> lib/intel_allocator.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/intel_allocator.c b/lib/intel_allocator.c
>> index e5b9457b8..96ffe40d5 100644
>> --- a/lib/intel_allocator.c
>> +++ b/lib/intel_allocator.c
>> @@ -584,8 +584,8 @@ static int handle_request(struct alloc_req *req, struct alloc_resp *resp)
>> break;
>>
>> case REQ_ALLOC:
>> - if (!req->alloc.alignment)
>> - req->alloc.alignment = ial->default_alignment;
>> + req->alloc.alignment = max(ial->default_alignment,
>> + req->alloc.alignment);
>
> It will work but change current allocator behavior regarding
> requested smaller alignment than default. I mean if allocator was
> created with (let's say) 64K alignment and we want to suballocate
> with 4K we can't do that with above code. All object regardless
> our alignment requirement will be aligned to 64K.
>
> Of course my need to have objects aligned to 4K is still reachable
> if I create allocator with 4K as enforced alignment and pass 64K
> as alignment argument on alloc().
Yeah, that seems fine to me. If I don't ask for any specific alignment
when creating the allocator it should just give me the "safe" default
imo, and all further allocations should be at least that, no matter what.
If something more exotic (which doesn't seem to be the common case) is
needed with being able to use say 4K, then manually setting that when
creating the allocator isn't too unreasonable, with then having finer
control with each individual allocation?
>
> What case are you solving with above code?
For my case I basically just want to force the allocator to always use
2M+ alignment, and I don't want random lib stuff passing in 4K/64K when
allocating an address and somehow overriding that. But perhaps I'm
misunderstanding how this all works?
>
> --
> Zbigniew
>
>>
>> resp->response_type = RESP_ALLOC;
>> resp->alloc.offset = ial->alloc(ial,
>> --
>> 2.41.0
>>
next prev parent reply other threads:[~2023-10-24 17:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 9:37 [igt-dev] [PATCH i-g-t v5 00/15] PAT and cache coherency support Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 01/15] drm-uapi/xe_drm: sync to get pat and coherency bits Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 02/15] lib/igt_fb: mark buffers as SCANOUT Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 03/15] lib/igt_draw: " Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 04/15] lib/xe: support cpu_caching and coh_mod for gem_create Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 05/15] tests/xe/mmap: add some tests for cpu_caching and coh_mode Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 06/15] lib/intel_pat: add helpers for common pat_index modes Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 07/15] lib/allocator: add get_offset_pat_index() helper Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 08/15] lib/intel_blt: support pat_index Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 09/15] lib/intel_buf: " Matthew Auld
2023-10-20 17:25 ` Niranjana Vishwanathapura
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 10/15] lib/xe_ioctl: update vm_bind to account for pat_index Matthew Auld
2023-10-20 16:59 ` Niranjana Vishwanathapura
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 11/15] lib/intel_allocator: treat default_alignment as the minimum Matthew Auld
2023-10-24 16:39 ` Zbigniew Kempczyński
2023-10-24 17:16 ` Matthew Auld [this message]
2023-11-02 9:53 ` Zbigniew Kempczyński
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 12/15] lib/intel_blt: tidy up alignment usage Matthew Auld
2023-10-20 9:37 ` [igt-dev] [PATCH i-g-t v5 13/15] lib/intel_batchbuffer: extend to include optional alignment Matthew Auld
2023-10-24 16:42 ` Zbigniew Kempczyński
2023-10-20 9:38 ` [igt-dev] [PATCH i-g-t v5 14/15] tests/xe: add some vm_bind pat_index tests Matthew Auld
2023-10-20 18:46 ` Niranjana Vishwanathapura
2023-10-20 9:38 ` [igt-dev] [PATCH i-g-t v5 15/15] tests/intel-ci/xe: add pat and caching related tests Matthew Auld
2023-10-23 23:09 ` [igt-dev] ✓ Fi.CI.BAT: success for PAT and cache coherency support (rev5) Patchwork
2023-10-24 0:13 ` [igt-dev] ✗ CI.xeBAT: failure " Patchwork
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=8de4e1c7-d353-620d-6920-05c4e1328808@intel.com \
--to=matthew.auld@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=zbigniew.kempczynski@intel.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