public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jerome Marchand <jmarchan@redhat.com>
To: Nitin Gupta <ngupta@vflare.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
	Linux Kernel List <linux-kernel@vger.kernel.org>,
	Robert Jennings <rcj@linux.vnet.ibm.com>,
	Jeff Moyer <jmoyer@redhat.com>
Subject: Re: [PATCH 3/4] Staging: zram: allow partial page operations
Date: Fri, 01 Jul 2011 11:47:49 +0200	[thread overview]
Message-ID: <4E0D97C5.5040005@redhat.com> (raw)
In-Reply-To: <4DF2493F.8040507@vflare.org>

On 06/10/2011 06:41 PM, Nitin Gupta wrote:
> On 06/10/2011 06:28 AM, Jerome Marchand wrote:
>> Commit 7b19b8d45b216ff3186f066b31937bdbde066f08 (zram: Prevent overflow
>> in logical block size) introduced ZRAM_LOGICAL_BLOCK_SIZE constant to
>> prevent overflow of logical block size on 64k page kernel.
>> However, the current implementation of zram only allow operation on block
>> of the same size as a page. That makes theorically legit 4k requests fail
>> on 64k page kernel.
>>
>> This patch makes zram allow operation on partial pages. Basically, it
>> means we still do operations on full pages internally, but only copy the
>> relevent segments from/to the user memory.
>>
> 
> Couldn't we just change struct queue_limits.logical_block_size type to 
> unsigned int or something so it could hold value of 64K? Then we could
> avoid making all these changes to handle partial page requests.

I've finally done some tests. At least FAT filesystems are unable to cope
with 64k logical blocks. Probably some other fs are affected too. I we want
to support them, zram need to handle operation on partial pages.

Jérôme

> 
> Thanks,
> Nitin

  parent reply	other threads:[~2011-07-01  9:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-10 13:28 [PATCH 1/4] Staging: zram: Remove useless offset calculation in handle_uncompressed_page() Jerome Marchand
2011-06-10 13:28 ` [PATCH 2/4] Staging: zram: Refactor zram_read/write() functions Jerome Marchand
2011-06-10 13:28   ` [PATCH 3/4] Staging: zram: allow partial page operations Jerome Marchand
2011-06-10 13:28     ` [PATCH 4/4] Staging: zram: Replace mutex lock by a R/W semaphore Jerome Marchand
2011-06-10 16:46       ` Nitin Gupta
2011-06-10 16:41     ` [PATCH 3/4] Staging: zram: allow partial page operations Nitin Gupta
2011-06-13  9:42       ` Jerome Marchand
2011-06-14 14:49         ` Jeff Moyer
2011-06-14 16:36           ` Martin K. Petersen
2011-07-01  9:47       ` Jerome Marchand [this message]
2011-07-14  3:19         ` Nitin Gupta
2011-07-14  3:25     ` Nitin Gupta
2011-07-14  3:24   ` [PATCH 2/4] Staging: zram: Refactor zram_read/write() functions Nitin Gupta
2011-06-10 16:38 ` [PATCH 1/4] Staging: zram: Remove useless offset calculation in handle_uncompressed_page() Nitin Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E0D97C5.5040005@redhat.com \
    --to=jmarchan@redhat.com \
    --cc=gregkh@suse.de \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ngupta@vflare.org \
    --cc=rcj@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox