Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2576680imd; Fri, 2 Nov 2018 13:57:23 -0700 (PDT) X-Google-Smtp-Source: AJdET5czogrmAWZkF+UBFRAdEw+JkZodCj+rIYYeSg1CiTgh4BhAM9nXoOj3v7U7eQ1gog5TeQ9F X-Received: by 2002:a63:2f86:: with SMTP id v128mr11794807pgv.407.1541192243557; Fri, 02 Nov 2018 13:57:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541192243; cv=none; d=google.com; s=arc-20160816; b=CroFPbc4bTYeegXIZxYJv0jZKTkBe+pKI/HvUaDJNZRssdSmQJqdjsUhofipZbV1RC vHHRWG7YNM3fckgKMRyhnZJ+ZndH8U2G49bJdVh0LrWSgR8UPejN5XmeQvASg7CxYYin t6zFK+4/UlfD8TQVlB3lHqGf8GQnKdVSuTDXpSn5HT1jpY6sbJlAeT4ulTe+9KUw7QhC xyFCVkfoIMemzjGfTrDoOKVSgS2FGemZinBP0E68YLkYJHc71znbCRyn8cmQZHaEvPy4 +nvrVC0QiNgeLPS1S6IoI50VSL2BSIYWyz5mLyOt+JVKrKU78zoFibnX1eahB3TsfFeg X8YA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=XJrVc0Rt0YYqU8Yntyq7QO3/VabNIJRfcrMBLdvJecg=; b=u9AhvlGfXs6h8dZGbSYzsLRYrecTfGG4eX9yYD+qam1n9rEdJDp7w+0995VXpyHxGM mhoP5lAfqQA+7hvTH/6S5Q8Y6A5C8v1PqX71C4kiXQBXO+uOpnWnMzKZXeUP44IwHrSJ K/cmjA7JuIbzP1NipqITweI9UnzGk1UxvwcjQGoHFna7neaLPk8eo6437unyzNzYyPde BjGMkK4pxLSoL+0bydOKN+PDPWqkrtrCjcZtxRbUjqX9Bfx9DWJN+dFWNgEmPuZjklZN QFKo56gb754UF5LhwrYG1Lb50/eOsde9cadyYC8o1HeX1NMosHXZDGNl0GvfBKK5IfHe lAXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f6-v6si35980556pgg.182.2018.11.02.13.57.09; Fri, 02 Nov 2018 13:57:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728253AbeKCGDt (ORCPT + 99 others); Sat, 3 Nov 2018 02:03:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:45897 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728193AbeKCGDs (ORCPT ); Sat, 3 Nov 2018 02:03:48 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2018 13:55:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,457,1534834800"; d="scan'208";a="102987150" Received: from kohsamui.iil.intel.com (HELO [10.236.193.12]) ([10.236.193.12]) by fmsmga004.fm.intel.com with ESMTP; 02 Nov 2018 13:55:03 -0700 Subject: Re: lib/genalloc To: Daniel Mentz Cc: Stephen Bates , Mathieu Desnoyers , lkml , labbott@redhat.com References: <4DECD467-AD45-419D-8F0F-1456863274FD@raithlin.com> From: Alexey Skidanov Message-ID: Date: Fri, 2 Nov 2018 22:56:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/2/18 9:17 PM, Daniel Mentz wrote: > On Thu, Nov 1, 2018 at 10:07 AM Alexey Skidanov > wrote: >> On 11/1/18 18:48, Stephen Bates wrote: >>>> I use gen_pool_first_fit_align() as pool allocation algorithm allocating >>>> buffers with requested alignment. But if a chunk base address is not >>>> aligned to the requested alignment(from some reason), the returned >>>> address is not aligned too. >>> >>> Alexey >>> >>> Can you try using gen_pool_first_fit_order_align()? Will that give you the alignment you need? >>> >>> Stephen >>> >>> >> I think it will not help me. Let's assume that the chunk base address is >> 0x2F400000 and I want to allocate 16MB aligned buffer. I get back the >> 0x2F400000. I think it happens because of this string in the >> gen_pool_alloc_algo(): >> >> addr = chunk->start_addr + ((unsigned long)start_bit << order); >> >> and the gen_pool_first_fit_align() implementation that doesn't take into >> account the "incorrect" chunk base alignment. > > gen_pool_first_fit_align() has no information about the chunk base > alignment. Hence, it can't take it into account. > > How do you request the alignment in your code? > > I agree with your analysis that gen_pool_first_fit_align() performs > alignment only with respect to the start of the chunk not the memory > address that gen_pool_alloc_algo() returns. I guess a solution would > be to only add chunks that satisfy all your alignment requirements. In > your case, you must only add chunks that are 16MB aligned. > I am unsure whether this is by design, but I believe it's the way that > the code currently works. > Daniel, I think the better solution is to use bitmap_find_next_zero_area_off() that receives the bit offset (CMA allocator uses it to solve the same issue). Of course, we need to pass the chunk base address to the gen_pool_first_fit_align(). What do you think? Thanks, Alexey