uest, complain, and
drop it completely. This way, as much of the request as possible is
preserved while still honoring the constraints given by the driver.
--
Frank Mayhar
310-460-4042
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
there's no sense getting information from the device and not using
> it. I guess you've talked me into it.
In fact that was the gist of the local bug I fixed with this. "The
driver has gone to the trouble of giving us this information, we should
use it."
--
Frank Mayhar
d on the
alignment and granularity anyway, so the overhead is pretty negligible
(and if the discard size goes to zero we short-circuit the process and
never go to the device at all).
--
Frank Mayhar
310-460-4042
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Mon, 2014-03-10 at 11:01 -0700, Frank Mayhar wrote:
> block: Force sector and nr_sects to device alignment and granularity.
Just FYI, I'll be going out for surgery next week and recovery for a
couple of months after that. If anyone has any further questions or
issues, either ask t
On Tue, 2014-03-11 at 11:15 -0400, Jeff Moyer wrote:
> Frank Mayhar writes:
>
> > block: Force sector and nr_sects to device alignment and granularity.
> >
> > In blkdev_issue_discard(), rather than sending an improperly-
> > aligned discard to the device (where it
eaves nothing to discard.
Without this change, certain flash drivers can report invalid
trim parameters (and will fail the command). Per tytso, "given
that discards are advisory, any part of the storage stack is
free to drop discard requests silently."
Signed-off-by: Frank Mayhar
Reviewe
st() would invoke the current
> elevator's elevator_dispatch_fn() callback. As all in-flight requests
> were drained, the elevator wouldn't contain any request but once
> bypass is confirmed we don't even know whether the elevator is even
> there. It might be in the pr
On Thu, 2014-01-23 at 13:56 -0500, Tejun Heo wrote:
> On Thu, Jan 23, 2014 at 10:38:33AM -0800, Frank Mayhar wrote:
> > On Wed, 2014-01-22 at 07:46 -0800, Frank Mayhar wrote:
> > > On Tue, 2014-01-21 at 07:58 -0800, Frank Mayhar wrote:
> > > > Replacing? Or adding
On Wed, 2014-01-22 at 07:46 -0800, Frank Mayhar wrote:
> On Tue, 2014-01-21 at 07:58 -0800, Frank Mayhar wrote:
> > Replacing? Or adding to? Is BYPASS always set when DYING is set? (My
> > guess is not but I haven't done an exhaustive analysis.) So the
> >
On Tue, 2014-01-21 at 07:58 -0800, Frank Mayhar wrote:
> Replacing? Or adding to? Is BYPASS always set when DYING is set? (My
> guess is not but I haven't done an exhaustive analysis.) So the
> relevant code snippet in __elv_next_request() would be:
> if (unlikel
On Sat, 2014-01-18 at 09:31 -0500, Tejun Heo wrote:
> Hello, Frank.
>
> On Fri, Jan 17, 2014 at 01:59:36PM -0800, Frank Mayhar wrote:
> > After investigation, it's clear that the elevator switch code is trying
> > to quiesce the request queue and sets the b
make sure that our needs are met and, while I'm at
it, make things a bit better for those who come after me.
--
Frank Mayhar
310-460-4042
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Tue, 2013-08-20 at 17:47 -0400, Mikulas Patocka wrote:
>
> On Tue, 20 Aug 2013, Frank Mayhar wrote:
>
> > On Tue, 2013-08-20 at 17:22 -0400, Mikulas Patocka wrote:
> > > On Fri, 16 Aug 2013, Frank Mayhar wrote:
> > > > The device mapper and some of
On Tue, 2013-08-20 at 17:44 -0400, Mikulas Patocka wrote:
> On Mon, 19 Aug 2013, Frank Mayhar wrote:
> > On Mon, 2013-08-19 at 10:00 -0400, Mike Snitzer wrote:
> > > Performance isn't the concern. The concern is: does DM allow for
> > > forward progress if t
On Tue, 2013-08-20 at 17:22 -0400, Mikulas Patocka wrote:
> On Fri, 16 Aug 2013, Frank Mayhar wrote:
> > The device mapper and some of its modules allocate memory pools at
> > various points when setting up a device. In some cases, these pools are
> > fairly large, for
r, as
you said it just seems reasonable to make these values configurable.
I'm also looking at making some similar constants in dm-verity and
dm-bufio configurable in the same way and for similar reasons.
--
Frank Mayhar
310-460-4042
--
To unsubscribe from this list: send the line "unsu
On Mon, 2013-08-19 at 09:40 -0400, Mike Snitzer wrote:
> On Sat, Aug 17 2013 at 8:30am -0400,
> Alasdair G Kergon wrote:
>
> > On Fri, Aug 16, 2013 at 03:55:21PM -0700, Frank Mayhar wrote:
> > > This patch fixes that by changing the hardcoded MIN_IOS (and certain
>
Sorry for the repeats, mailer issues (was supposed to go to dm-devel).
--
Frank Mayhar
310-460-4042
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Ping? Has anyone glanced at this?
On Fri, 2013-08-09 at 10:48 -0700, Frank Mayhar wrote:
> The device mapper and some of its modules allocate memory pools at
> various points when setting up a device. In some cases, these pools are
> fairly large, for example the multipath module al
been unchanged since at least 2006.
Signed-off-by: Frank Mayhar
---
drivers/md/dm-crypt.c | 63 +++
drivers/md/dm-io.c| 58 +--
drivers/md/dm-mpath.c | 48 ++-
EEMPT+GnuC-4.1.2+Glibc-2.5 = Reproducible.
>
> Not sure what the original reporter's $ARCH was.
Several, among which were i686+SMP+GnuC-4.0.3+Glibc-2.3.6. No PREEMPT.
Linux 2.6.18, 2.6.21 and 2.6.24-rc4.
--
Frank Mayhar <[EMAIL PROTECTED]>
Google, Inc.
--
To unsubscr
-o hangc-2 hangc-2.o
Run with
hangc-2 4500 4500
--
Frank Mayhar <[EMAIL PROTECTED]>
Google, Inc.
#include
#include
#include
#include
#include
#include
#include
#include
#include
static void *
LinuxThreadTestRoutine(
void *pid)
{
pid_t *pid_ptr = (pid_t *) (pid);
lso opened a Bugzilla bug for this issue, with the same
information and testcase, at
http://bugzilla.kernel.org/show_bug.cgi?id=9906
--
Frank Mayhar <[EMAIL PROTECTED]>
Google, Inc.
#include
#include
#include
#include
#include
#include
#include
#include
#include
static void *
L
ed it while I was sick; this time I took
my time and I think I got it right.
A test program that has been run against a number of systems (of which
only FreeBSD and Linux 2.6 with this patch applied passed) is also
available at
http://www.exit.com/Archives/Linux/
Signed-off-by: Frank M
For some reason, the first twenty times I read the doc, I missed the
"terminated and waited-for" bit for RUSAGE_CHILDREN.
Patch withdrawn, for the moment anyway. (And the right fix won't solve
our problem, sigh.)
--
Frank Mayhar <[EMAIL PROTECTED]>
Google, Inc.
-
To unsub
elf was lifted from task_mem() in proc/task_mmu.c. The only
questionable bit is where it does the read_lock() of the tasklist_lock;
although it seems safe enough, I would appreciate if those more
knowledgeable about that locking vet it (briefly) for safety.
Signed-off-by: Frank Mayhar <[EMAIL PROT
26 matches
Mail list logo
