Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753121AbaJWXOi (ORCPT ); Thu, 23 Oct 2014 19:14:38 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:37371 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750964AbaJWXOg (ORCPT ); Thu, 23 Oct 2014 19:14:36 -0400 MIME-Version: 1.0 In-Reply-To: <1413287968-13940-1-git-send-email-heesub.shin@samsung.com> References: <1413287968-13940-1-git-send-email-heesub.shin@samsung.com> From: Dan Streetman Date: Thu, 23 Oct 2014 19:14:15 -0400 X-Google-Sender-Auth: abCacRno7hhSn3FahdGDiubJbUg Message-ID: Subject: Re: [RFC PATCH 0/9] mm/zbud: support highmem pages To: Seth Jennings Cc: Andrew Morton , Heesub Shin , Nitin Gupta , Linux-MM , linux-kernel , Sunae Seo Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 14, 2014 at 7:59 AM, Heesub Shin wrote: > zbud is a memory allocator for storing compressed data pages. It keeps > two data objects of arbitrary size on a single page. This simple design > provides very deterministic behavior on reclamation, which is one of > reasons why zswap selected zbud as a default allocator over zsmalloc. > > Unlike zsmalloc, however, zbud does not support highmem. This is > problomatic especially on 32-bit machines having relatively small > lowmem. Compressing anonymous pages from highmem and storing them into > lowmem could eat up lowmem spaces. > > This limitation is due to the fact that zbud manages its internal data > structures on zbud_header which is kept in the head of zbud_page. For > example, zbud_pages are tracked by several lists and have some status > information, which are being referenced at any time by the kernel. Thus, > zbud_pages should be allocated on a memory region directly mapped, > lowmem. > > After some digging out, I found that internal data structures of zbud > can be kept in the struct page, the same way as zsmalloc does. So, this > series moves out all fields in zbud_header to struct page. Though it > alters quite a lot, it does not add any functional differences except > highmem support. I am afraid that this kind of modification abusing > several fields in struct page would be ok. Seth, have you had a chance to review this yet? I'm going to try to take a look at it next week if you haven't yet. Letting zbud use highmem would be a good thing. > > Heesub Shin (9): > mm/zbud: tidy up a bit > mm/zbud: remove buddied list from zbud_pool > mm/zbud: remove lru from zbud_header > mm/zbud: remove first|last_chunks from zbud_header > mm/zbud: encode zbud handle using struct page > mm/zbud: remove list_head for buddied list from zbud_header > mm/zbud: drop zbud_header > mm/zbud: allow clients to use highmem pages > mm/zswap: use highmem pages for compressed pool > > mm/zbud.c | 244 ++++++++++++++++++++++++++++++------------------------------- > mm/zswap.c | 4 +- > 2 files changed, 121 insertions(+), 127 deletions(-) > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/