On Tue, 20 Aug 2013, Frank Mayhar wrote:
> On Tue, 2013-08-20 at 18:24 -0400, Mike Snitzer wrote:
> > Mikulas' point is that you cannot reduce the size to smaller than 1.
> > And aside from rq-based DM, 1 is sufficient to allow for forward
> > progress even when memory is completely consumed.
>
On Tue, 2013-08-20 at 18:24 -0400, Mike Snitzer wrote:
> Mikulas' point is that you cannot reduce the size to smaller than 1.
> And aside from rq-based DM, 1 is sufficient to allow for forward
> progress even when memory is completely consumed.
>
> A patch that simply changes them to 1 but makes t
On Tue, 20 Aug 2013, Mike Snitzer wrote:
> Mikulas' point is that you cannot reduce the size to smaller than 1.
> And aside from rq-based DM, 1 is sufficient to allow for forward
> progress even when memory is completely consumed.
>
> A patch that simply changes them to 1 but makes the rq-based
On Tue, Aug 20 2013 at 5:57pm -0400,
Frank Mayhar wrote:
> 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:
> > > > > T
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 its modules allocate memory pools at
> > > >
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 the system's memory is completely exhaust
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 its modules allocate memory pools at
> > > various points when setting up a device. In some cases, these pools ar
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 the system's memory is completely exhausted?
> >
> > This is why request-based has such an extensive re
On Mon, 19 Aug 2013, Mike Snitzer wrote:
> On Fri, Aug 16 2013 at 6:55pm -0400,
> 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 multipa
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 example the multipath module
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 example the multipath module allocates a 256-entry
> pool and the dm itself allocates three
On Mon, Aug 19 2013 at 1:54pm -0400,
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 the system's memory is completely exhausted?
> >
> > This is why request-based has such
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 the system's memory is completely exhausted?
>
> This is why request-based has such an extensive reserve, because it
> needs to account for cloning the l
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
> > > other) #defines in dm-cryp
On Fri, Aug 16 2013 at 6:55pm -0400,
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 allocates a 256-entry
> pool and the dm itself
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
> > other) #defines in dm-crypt, dm-io, dm-mpath, dm-snap and dm itself to
> > sysctl-modifiable
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
> other) #defines in dm-crypt, dm-io, dm-mpath, dm-snap and dm itself to
> sysctl-modifiable values. This lets us change the size of these pools
> on the fly, we can
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-info.html
P
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 allocates a 256
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 allocates a 256-entry
pool and the dm itself allocates three of that size. In a
memory-constrained environment
20 matches
Mail list logo
