* Huge memory allocation
@ 2011-03-01 13:04 Eli Malul
2011-03-01 13:46 ` Alasdair G Kergon
0 siblings, 1 reply; 6+ messages in thread
From: Eli Malul @ 2011-03-01 13:04 UTC (permalink / raw)
To: dm-devel
[-- Attachment #1.1: Type: text/plain, Size: 232 bytes --]
dm_malloc_aux do not allow memory allocation greater than 50000000.
Is there a reason for that?
I would like to change this limitation to 100000000.
Do you see a problem with that?
Thanks,
Eli
[-- Attachment #1.2: Type: text/html, Size: 2735 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Huge memory allocation
2011-03-01 13:04 Huge memory allocation Eli Malul
@ 2011-03-01 13:46 ` Alasdair G Kergon
2011-03-03 8:05 ` Eli Malul
0 siblings, 1 reply; 6+ messages in thread
From: Alasdair G Kergon @ 2011-03-01 13:46 UTC (permalink / raw)
To: Eli Malul; +Cc: dm-devel
On Tue, Mar 01, 2011 at 03:04:56PM +0200, Eli Malul wrote:
> dm_malloc_aux do not allow memory allocation greater than 50000000.
That was to catch software bugs: it was a number bigger than ever
needed. Change it if you need to, but I need stronger evidence
of the need for your particular way of doing things before
I'll change it in the upstream tree!
Alasdair
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Huge memory allocation
2011-03-01 13:46 ` Alasdair G Kergon
@ 2011-03-03 8:05 ` Eli Malul
2011-03-03 8:41 ` Zdenek Kabelac
0 siblings, 1 reply; 6+ messages in thread
From: Eli Malul @ 2011-03-03 8:05 UTC (permalink / raw)
To: Alasdair G Kergon; +Cc: dm-devel
I am expecting to have lots of (up to million) scattered extents across
some volumes which I am required to mirror.
Since mirror mapped device with a table that large consume unbearable
amount of memory (e.g. for 10,000 extents I saw about 6 Giga of memory
allocated by the device-mapper) I am going to create two linear devices
which maps these extents and mirror them.
In addition, I am required to preserve the original extent's offsets
since they are an existing user data used by DB applications.
To achieve that I will create another linear device to simulate the
original extent's offsets which shall be mapped to the created mirrored
device so, the client will continue to read and write the same offsets.
-----Original Message-----
From: Alasdair G Kergon [mailto:agk@redhat.com]
Sent: Tuesday, March 01, 2011 3:46 PM
To: Eli Malul
Cc: dm-devel@redhat.com
Subject: Re: [dm-devel] Huge memory allocation
On Tue, Mar 01, 2011 at 03:04:56PM +0200, Eli Malul wrote:
> dm_malloc_aux do not allow memory allocation greater than 50000000.
That was to catch software bugs: it was a number bigger than ever
needed. Change it if you need to, but I need stronger evidence
of the need for your particular way of doing things before
I'll change it in the upstream tree!
Alasdair
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Huge memory allocation
2011-03-03 8:05 ` Eli Malul
@ 2011-03-03 8:41 ` Zdenek Kabelac
2011-03-03 8:58 ` Eli Malul
0 siblings, 1 reply; 6+ messages in thread
From: Zdenek Kabelac @ 2011-03-03 8:41 UTC (permalink / raw)
Cc: device-mapper development, Eli Malul
Dne 3.3.2011 09:05, Eli Malul napsal(a):
> I am expecting to have lots of (up to million) scattered extents across
> some volumes which I am required to mirror.
> Since mirror mapped device with a table that large consume unbearable
> amount of memory (e.g. for 10,000 extents I saw about 6 Giga of memory
> allocated by the device-mapper) I am going to create two linear devices
> which maps these extents and mirror them.
>
> In addition, I am required to preserve the original extent's offsets
> since they are an existing user data used by DB applications.
> To achieve that I will create another linear device to simulate the
> original extent's offsets which shall be mapped to the created mirrored
> device so, the client will continue to read and write the same offsets.
>
Aren't you trying to reinvent dm-replicator target ?
(available as an extra kernel patch)
Maybe you should first describe exactly what are you trying to achieve.
I'd guess there would be better ways to achieve that goal.
Updating kernel tables is expensive operation - especially if you plan to have
its size in the range of multiple megabytes - so it looks like wrong plan...
Zdenek
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Huge memory allocation
2011-03-03 8:41 ` Zdenek Kabelac
@ 2011-03-03 8:58 ` Eli Malul
2011-03-03 10:00 ` Zdenek Kabelac
0 siblings, 1 reply; 6+ messages in thread
From: Eli Malul @ 2011-03-03 8:58 UTC (permalink / raw)
To: Zdenek Kabelac,
undisclosed-recipients <undisclosed-recipients>
Cc: device-mapper development
I would like to accelerate read IO performance for user data which
resides on one machine (with low IO performance due to slow media) and
might be scattered on many different extents by mirroring these extents
to another machine with much better IO performance and direct read
requests to that machine (I already added a patch to the dm-raid1.c to
set preferred read capability).
Any suggestions would be appreciated...
-----Original Message-----
From: Zdenek Kabelac [mailto:zkabelac@redhat.com]
Sent: Thursday, March 03, 2011 10:42 AM
To: undisclosed-recipients
Cc: Eli Malul; device-mapper development
Subject: Re: [dm-devel] Huge memory allocation
Dne 3.3.2011 09:05, Eli Malul napsal(a):
> I am expecting to have lots of (up to million) scattered extents
across
> some volumes which I am required to mirror.
> Since mirror mapped device with a table that large consume unbearable
> amount of memory (e.g. for 10,000 extents I saw about 6 Giga of memory
> allocated by the device-mapper) I am going to create two linear
devices
> which maps these extents and mirror them.
>
> In addition, I am required to preserve the original extent's offsets
> since they are an existing user data used by DB applications.
> To achieve that I will create another linear device to simulate the
> original extent's offsets which shall be mapped to the created
mirrored
> device so, the client will continue to read and write the same
offsets.
>
Aren't you trying to reinvent dm-replicator target ?
(available as an extra kernel patch)
Maybe you should first describe exactly what are you trying to achieve.
I'd guess there would be better ways to achieve that goal.
Updating kernel tables is expensive operation - especially if you plan
to have
its size in the range of multiple megabytes - so it looks like wrong
plan...
Zdenek
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Huge memory allocation
2011-03-03 8:58 ` Eli Malul
@ 2011-03-03 10:00 ` Zdenek Kabelac
0 siblings, 0 replies; 6+ messages in thread
From: Zdenek Kabelac @ 2011-03-03 10:00 UTC (permalink / raw)
To: dm-devel
Dne 3.3.2011 09:58, Eli Malul napsal(a):
> I would like to accelerate read IO performance for user data which
> resides on one machine (with low IO performance due to slow media) and
> might be scattered on many different extents by mirroring these extents
> to another machine with much better IO performance and direct read
> requests to that machine (I already added a patch to the dm-raid1.c to
> set preferred read capability).
>
> Any suggestions would be appreciated...
There were some projects like dm cache and probably few others.
(http://visa.cis.fiu.edu/ming/dmcache/)
You will need to create a new dm target for the thing you try to achieve.
Handling this in userspace could only serve for prototype thing.
Structures in libdm are not designed to work efficiently with millions of
extents passed to kernel through ioctl operation - this path isn't probably
the best one...
You may still want to check dm-replicator or drdb technology.
But it all depends on how do you plan to synchronize above the block level,
and how the write operation is supposed to handled.
Zdenek
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-03 10:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-01 13:04 Huge memory allocation Eli Malul
2011-03-01 13:46 ` Alasdair G Kergon
2011-03-03 8:05 ` Eli Malul
2011-03-03 8:41 ` Zdenek Kabelac
2011-03-03 8:58 ` Eli Malul
2011-03-03 10:00 ` Zdenek Kabelac
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox