[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/6] accel: accel_available() function
From: |
Claudio Fontana |
Subject: |
Re: [PATCH v2 2/6] accel: accel_available() function |
Date: |
Fri, 27 Nov 2020 15:58:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
On 11/27/20 3:45 PM, Markus Armbruster wrote:
> Claudio Fontana <cfontana@suse.de> writes:
>
>> On 11/26/20 10:48 PM, Eduardo Habkost wrote:
>>> On Thu, Nov 26, 2020 at 10:06:03PM +0100, Claudio Fontana wrote:
>>>> On 11/26/20 3:25 PM, Paolo Bonzini wrote:
>>>>> On 26/11/20 15:13, Claudio Fontana wrote:
>>>>>> One option I see is simply to document the behavior where
>>>>>> accel_available() is declared in accel.h (ie do not use in fast
>>>>>> path), as well as in accel_find() actually, so that both accel_find()
>>>>>> and accel_available() are avoided in fast path and avoid being called
>>>>>> frequently at runtime.
>>>>>>
>>>>>> Another option could be to remove the allocation completely, and use
>>>>>> for example accel_find(ACCEL_CLASS_NAME("tcg")), or another option
>>>>>> again would be to remove the allocation and use either a fixed buffer
>>>>>> + snprintf, or alloca -like builtin code to use the stack, ...
>>>>>>
>>>>>> Not a big deal, but with a general utility and short name like
>>>>>> accel_available(name) it might be tempting to use this more in the
>>>>>> future?
>>>>>
>>>>> I think it's just that the usecase is not that common. "Is this
>>>>> accelerator compiled in the binary" is not something you need after
>>>>> startup (or if querying the monitor).
>>>>>
>>>>> Paolo
>>>>>
>>>>>
>>>>
>>>> A script that repeatedly uses the QMP interface to query for
>>>> the status could generate fragmentation this way I think.
>>>
>>> Is this a problem? Today, execution of a "query-kvm" command
>>> calls g_malloc() 37 times.
>>>
>>
>> Not ideal in my view, but not the end of the world either.
>
> QMP's appetite for malloc is roughly comparable to a pig's for truffles.
>
:-)
Btw, do we have limits on the maximum size of these objects? I mean, a single
QMP command,
a single QEMU object type name, etc?
In this case we could do some overall improvement there, and might even avoid
some problems down the road..
Ciao,
Claudio
- [PATCH v2 0/6] arch_init.c cleanup, Eduardo Habkost, 2020/11/25
- [PATCH v2 2/6] accel: accel_available() function, Eduardo Habkost, 2020/11/25
- Re: [PATCH v2 2/6] accel: accel_available() function, Claudio Fontana, 2020/11/26
- Re: [PATCH v2 2/6] accel: accel_available() function, Eduardo Habkost, 2020/11/26
- Re: [PATCH v2 2/6] accel: accel_available() function, Claudio Fontana, 2020/11/26
- Re: [PATCH v2 2/6] accel: accel_available() function, Paolo Bonzini, 2020/11/26
- Re: [PATCH v2 2/6] accel: accel_available() function, Claudio Fontana, 2020/11/26
- Re: [PATCH v2 2/6] accel: accel_available() function, Eduardo Habkost, 2020/11/26
- Re: [PATCH v2 2/6] accel: accel_available() function, Claudio Fontana, 2020/11/27
- Re: [PATCH v2 2/6] accel: accel_available() function, Markus Armbruster, 2020/11/27
- Re: [PATCH v2 2/6] accel: accel_available() function,
Claudio Fontana <=
- Re: [PATCH v2 2/6] accel: accel_available() function, Markus Armbruster, 2020/11/27
- Re: [PATCH v2 2/6] accel: accel_available() function, Paolo Bonzini, 2020/11/27
Re: [PATCH v2 2/6] accel: accel_available() function, Cornelia Huck, 2020/11/27
[PATCH v2 3/6] kvm: Remove kvm_available() function, Eduardo Habkost, 2020/11/25
[PATCH v2 1/6] arch_init: Move QEMU_ARCH definitions to cpu.h, Eduardo Habkost, 2020/11/25
[PATCH v2 4/6] xen: Delete xen_available() function, Eduardo Habkost, 2020/11/25