From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aaxjz-0003p9-KE for mharc-grub-devel@gnu.org; Tue, 01 Mar 2016 22:46:23 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaxjx-0003oY-LF for grub-devel@gnu.org; Tue, 01 Mar 2016 22:46:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaxju-00053L-Dm for grub-devel@gnu.org; Tue, 01 Mar 2016 22:46:21 -0500 Received: from mail-lb0-x22d.google.com ([2a00:1450:4010:c04::22d]:33033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaxju-00052m-5H for grub-devel@gnu.org; Tue, 01 Mar 2016 22:46:18 -0500 Received: by mail-lb0-x22d.google.com with SMTP id k15so11555lbg.0 for ; Tue, 01 Mar 2016 19:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=N6DHwar4TQRrWJneZZtA8Mqfhs7n19Peusz4wXOZOkM=; b=C1yDFIUCPF6opqVl/BsCy1K1jUzOkjJBGEVyYgsoQiePUQFTAD3yX/zGtZfxjIds6r V9tkOxCQqa8yXkz2MLhjbyGRZ+9dLXOFT7oJrs+fBIjmRGdWKEmIF/Y+1Wkxdp0zA2rF Onmmf+g8U2/Cc4ciw7qM7e70lM0565XKYT0JsBqm0q7kt8YB4S/n2ZWQp3aRzL0Vpo7C 44g0LTAqbQb8bpCsSYDt/gJJzvvozEMzWXTcqoCDsCpumoHPEjvk5EqyeEk/sHL6JtTg XpGSuI8PY+Hksl8RfICET2z32N4PKJWm/OmKd3WmBpf3R8jnzEwB5/fzb94xAfNInSmQ gQdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=N6DHwar4TQRrWJneZZtA8Mqfhs7n19Peusz4wXOZOkM=; b=BWHuDpnWFUeVXG9tetI0ZB9iAP3upGkQGLN8X5DbijRGKKJiwSyXOBtdceKITSnpQL I1D8HSql6VzR3rNthPBLorEhwXkinKA0EwVQFj+DkE3rHcz4R2cTWFcKSiRR0FnHmU74 XcO3XIRM0DYzMKSqaOg/2x5Z8dBAZoSj65ilH5XSyTYVIt8G6Ri9CqviPxsxRfvxgkb1 waQm0zOnSgqy6lCstVyqsLZVY/7FvFPwTB+d2G+0BH3LO9j2HrAu7O2vg1Oc7u5MsSzE cMu6Jdsr2dxWafpwAS/hu7I71fi/O3Bgoy2ZSRP33lbiOm8uDEVur8NJO/9FUqGdRC3j zHgQ== X-Gm-Message-State: AD7BkJIXwzlBUQhi+QvaRdmvba9pd+RAX+NWxyhzNMd/7QyMW3a8mRF/v1oEHZcE9uSj+A== X-Received: by 10.112.38.104 with SMTP id f8mr9078071lbk.115.1456890376811; Tue, 01 Mar 2016 19:46:16 -0800 (PST) Received: from [192.168.1.41] (ppp109-252-76-159.pppoe.spdop.ru. [109.252.76.159]) by smtp.gmail.com with ESMTPSA id su3sm1243710lbb.21.2016.03.01.19.46.15 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 19:46:15 -0800 (PST) Subject: Re: [PATCH v2 3/3] disk: read into cache directly To: grub-devel@gnu.org References: <1456877652-19389-1-git-send-email-leif.lindholm@linaro.org> <1456877652-19389-4-git-send-email-leif.lindholm@linaro.org> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56D66206.8040201@gmail.com> Date: Wed, 2 Mar 2016 06:46:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::22d X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 03:46:22 -0000 02.03.2016 03:22, Vladimir 'phcoder' Serbinenko пишет: > Is there any way this patch reclaims unused memory in case of partial cache > eviction? Not yet, I wanted to make sure base looks sane first. Are there any cases of partial eviction besides blocklist write? > If not it could potentially water lots of memory. One thing you > need to consider is that initrd for Solaris can easily be 60% of total RAM > (300 MiB on 512MiB machine) What if requested read is bigger than risk > cache size? > Not sure I parse it; but yes, it puts more stress on cache by requiring unfragmented memory. If we follow this route we need to gracefully fall back to cache element size. Do we have any reasonable chance to separate aligned and non-aligned memory pools?