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

Re: [PATCH 1/9] gnttab: defer allocation of maptrack frames table

  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 6 Sep 2021 15:29:12 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G3OCOX0BR8N3bNEaVRo41nPsf4k/oWlMETypATXxQfg=; b=diUTTM9UGY6I+wylvSBInV5iPwdi5k/au3IuaEB4r3sT5mzx39mzpF4WR3uzWZkbniKXe0vFCKetzJWuKPWvjLNJUUYRU9Eb3yh5seFekASTg8pFU1jcmLbGfyRsAiqDzJbKaUn4ub8XW5p5EIkHJvAwghx6acHU18Nh4eA63+gMwCrEB2nm3EVl6NigVIhGIlT5/AbsDFr3jbe5P87IQXf+UmlR/gHLE0IXNbjiWGVZ0WMKWXYigIkRC1i3xuAQqq4NpVwiXDefF0nrErO/7wh+fZiw6bFwIzQO4s5dQG48cfIUynFk1Kx6jdomkRr0R7IVo3/RzBfwVafOkJ9SSg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TrwQPq9DNZIcxM2j9SlRty6gLcEdn6aTmreLx2n/ifvO3fFzkC2UGQrnAAnkiagTFMmsDBfjFSwKvWI3kV/GdE+92lokw2uFPoUQCRyikrKQNcxx2ewu8ziEpucyVR2E/W8iE4IZitLcyJfCF8sJX+P1jaHadcrP1nsc8aZMLnsueNdh3ui0EX5sHhwvHFpT85nskDWClXeJ03GPchkYXyizZijAxKzyuojY2ZHqLz5O5YuJxx6fOxOXuNoNsIGnv+Ndn8JoQmYh9hM2kKhvOhXV5pLi49uDHJ8u8cjytuiJLQvIJ+3bZaj/o45MIqQA6MSnequgFhUXQxKgTYsEDA==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 06 Sep 2021 13:29:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06.09.2021 15:13, Julien Grall wrote:
> On 26/08/2021 11:09, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -633,6 +633,34 @@ get_maptrack_handle(
>>       if ( likely(handle != INVALID_MAPTRACK_HANDLE) )
>>           return handle;
>> +    if ( unlikely(!read_atomic(&lgt->maptrack)) )
>> +    {
>> +        struct grant_mapping **maptrack = NULL;
>> +
>> +        if ( lgt->max_maptrack_frames )
>> +            maptrack = vzalloc(lgt->max_maptrack_frames * 
>> sizeof(*maptrack));
> While I understand that allocating with a lock is bad idea, I don't like 
> the fact that multiple vCPUs racing each other would result to 
> temporarily allocate more memory.
> If moving the call within the lock is not a solution, would using a loop 
> with a cmpxchg() a solution to block the other vCPU?

As with any such loop the question then is for how long to retry. No matter
what (static) loop bound you choose, if you exceed it you would return an
error to the caller for no reason.

As to the value to store by cmpxchg() - were you thinking of some "alloc in
progress" marker? You obviously can't store the result of the allocation
before actually doing the allocation, yet it is unnecessary allocations
that you want to avoid (i.e. to achieve your goal the allocation would need
to come after the cmpxchg()). A marker would further complicate the other
code here, even if (maybe) just slightly ...




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.