qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/6] accel: accel_available() function


From: Markus Armbruster
Subject: Re: [PATCH v2 2/6] accel: accel_available() function
Date: Fri, 27 Nov 2020 15:45:37 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]