* Re: Fw: [Lhms-devel] Making hotremovable attribute with memory section[0/4]
@ 2004-08-17 0:27 ` Alan Cox
0 siblings, 0 replies; 12+ messages in thread
From: Alan Cox @ 2004-08-17 0:27 UTC (permalink / raw)
To: Dave Hansen
Cc: Yasunori Goto, Linux Kernel Mailing List, linux-mm,
Martin J. Bligh
On Maw, 2004-08-17 at 00:35, Dave Hansen wrote:
> In any case, the question of the day is, does anyone have any
> suggestions on how to create 2 separate pools for pages: one
> representing hot-removable pages, and the other pages that may not be
> removed?
How do you define the split. There are lots of circumstances where user
pages can be pinned for a long (near indefinite) period of time and used
for DMA.
Consider
- Video capture
- AGP Gart
- AGP based framebuffer (intel i8/9xx)
- O_DIRECT I/O
There are also things like cluster interconnects, sendfile and the like
involved here.
Alan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Lhms-devel] Making hotremovable attribute with memory section[0/4]
2004-08-17 0:27 ` Alan Cox
@ 2004-08-17 5:15 ` Yasunori Goto
-1 siblings, 0 replies; 12+ messages in thread
From: Yasunori Goto @ 2004-08-17 5:15 UTC (permalink / raw)
To: Alan Cox
Cc: Dave Hansen, Linux Kernel Mailing List, linux-mm, Martin J. Bligh
Hello.
> On Maw, 2004-08-17 at 00:35, Dave Hansen wrote:
> > In any case, the question of the day is, does anyone have any
> > suggestions on how to create 2 separate pools for pages: one
> > representing hot-removable pages, and the other pages that may not be
> > removed?
>
> How do you define the split. There are lots of circumstances where user
> pages can be pinned for a long (near indefinite) period of time and used
> for DMA.
Basically, kernel have to wait of completion of I/O.
> Consider
> - Video capture
> - AGP Gart
> - AGP based framebuffer (intel i8/9xx)
I didn't consider deeply about this, because usually
enterprise server doesn't need Video capture feature or AGP.
It is usually controlled from other machine.
If it is really necessary, kernel might have to wait
I/O completion or driver modification is necessary.
> - O_DIRECT I/O
I can use page remmaping method by Iwamoto-san.
(See: http://people.valinux.co.jp/~iwamoto/mh.html#remap)
I guess that many case can be saved by this.
> There are also things like cluster interconnects, sendfile and the like
> involved here.
In sendfile case, kernel will wait too. Sooner or later, it will be
timeout.
Thank you for your comment.
Bye.
--
Yasunori Goto <ygoto at us.fujitsu.com>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Lhms-devel] Making hotremovable attribute with memory section[0/4]
@ 2004-08-17 5:15 ` Yasunori Goto
0 siblings, 0 replies; 12+ messages in thread
From: Yasunori Goto @ 2004-08-17 5:15 UTC (permalink / raw)
To: Alan Cox
Cc: Dave Hansen, Linux Kernel Mailing List, linux-mm, Martin J. Bligh
Hello.
> On Maw, 2004-08-17 at 00:35, Dave Hansen wrote:
> > In any case, the question of the day is, does anyone have any
> > suggestions on how to create 2 separate pools for pages: one
> > representing hot-removable pages, and the other pages that may not be
> > removed?
>
> How do you define the split. There are lots of circumstances where user
> pages can be pinned for a long (near indefinite) period of time and used
> for DMA.
Basically, kernel have to wait of completion of I/O.
> Consider
> - Video capture
> - AGP Gart
> - AGP based framebuffer (intel i8/9xx)
I didn't consider deeply about this, because usually
enterprise server doesn't need Video capture feature or AGP.
It is usually controlled from other machine.
If it is really necessary, kernel might have to wait
I/O completion or driver modification is necessary.
> - O_DIRECT I/O
I can use page remmaping method by Iwamoto-san.
(See: http://people.valinux.co.jp/~iwamoto/mh.html#remap)
I guess that many case can be saved by this.
> There are also things like cluster interconnects, sendfile and the like
> involved here.
In sendfile case, kernel will wait too. Sooner or later, it will be
timeout.
Thank you for your comment.
Bye.
--
Yasunori Goto <ygoto at us.fujitsu.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Lhms-devel] Making hotremovable attribute with memory section[0/4]
2004-08-17 5:15 ` Yasunori Goto
@ 2004-08-17 9:58 ` Dave Jones
-1 siblings, 0 replies; 12+ messages in thread
From: Dave Jones @ 2004-08-17 9:58 UTC (permalink / raw)
To: Yasunori Goto
Cc: Alan Cox, Dave Hansen, Linux Kernel Mailing List, linux-mm,
Martin J. Bligh
On Mon, Aug 16, 2004 at 10:15:51PM -0700, Yasunori Goto wrote:
> > Consider
> > - Video capture
> > - AGP Gart
> > - AGP based framebuffer (intel i8/9xx)
>
> I didn't consider deeply about this, because usually
> enterprise server doesn't need Video capture feature or AGP.
AMD64's IOMMU is implemented using the AGP GART.
This feature is certainly used in server environments.
Dave
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Lhms-devel] Making hotremovable attribute with memory section[0/4]
@ 2004-08-17 9:58 ` Dave Jones
0 siblings, 0 replies; 12+ messages in thread
From: Dave Jones @ 2004-08-17 9:58 UTC (permalink / raw)
To: Yasunori Goto
Cc: Alan Cox, Dave Hansen, Linux Kernel Mailing List, linux-mm,
Martin J. Bligh
On Mon, Aug 16, 2004 at 10:15:51PM -0700, Yasunori Goto wrote:
> > Consider
> > - Video capture
> > - AGP Gart
> > - AGP based framebuffer (intel i8/9xx)
>
> I didn't consider deeply about this, because usually
> enterprise server doesn't need Video capture feature or AGP.
AMD64's IOMMU is implemented using the AGP GART.
This feature is certainly used in server environments.
Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fw: [Lhms-devel] Making hotremovable attribute with memory section[0/4]
2004-08-17 0:27 ` Alan Cox
@ 2004-08-17 7:52 ` Dave Hansen
-1 siblings, 0 replies; 12+ messages in thread
From: Dave Hansen @ 2004-08-17 7:52 UTC (permalink / raw)
To: Alan Cox
Cc: Yasunori Goto, Linux Kernel Mailing List, linux-mm,
Martin J. Bligh
On Mon, 2004-08-16 at 17:27, Alan Cox wrote:
> On Maw, 2004-08-17 at 00:35, Dave Hansen wrote:
> > In any case, the question of the day is, does anyone have any
> > suggestions on how to create 2 separate pools for pages: one
> > representing hot-removable pages, and the other pages that may not be
> > removed?
>
> How do you define the split.
We would hope not to have to define the split explicitly. Since we're
hotplugging memory and resizing zones anyway, it shouldn't be a real
functional problem to balance memory between the 2 states, no matter how
it is implemented.
> There are lots of circumstances where user
> pages can be pinned for a long (near indefinite) period of time and used
> for DMA.
For simple cases, anything tricky like DMA will simply be in an
unremovable area. However, some platforms like ppc64 logical
partitions, require firmware notification of DMA areas. The ppc64
firmware provides consistent remapping functionality for these DMA areas
if they ever need to be hot-swapped.
> Consider
> - Video capture
> - AGP Gart
> - AGP based framebuffer (intel i8/9xx)
> - O_DIRECT I/O
>
> There are also things like cluster interconnects, sendfile and the like
> involved here.
When we get to trying to forcefully migrate the kinds of memory that you
reference above, we'll likely need firmware support like ppc64 has. The
other option is to have some driver callbacks to tell them to reallocate
their buffers into new areas, if that's even possible. But, even that's
not something I see ever happening to the entire tree, more likely a
small subset of the drivers that really need it.
-- Dave
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fw: [Lhms-devel] Making hotremovable attribute with memory section[0/4]
@ 2004-08-17 7:52 ` Dave Hansen
0 siblings, 0 replies; 12+ messages in thread
From: Dave Hansen @ 2004-08-17 7:52 UTC (permalink / raw)
To: Alan Cox
Cc: Yasunori Goto, Linux Kernel Mailing List, linux-mm,
Martin J. Bligh
On Mon, 2004-08-16 at 17:27, Alan Cox wrote:
> On Maw, 2004-08-17 at 00:35, Dave Hansen wrote:
> > In any case, the question of the day is, does anyone have any
> > suggestions on how to create 2 separate pools for pages: one
> > representing hot-removable pages, and the other pages that may not be
> > removed?
>
> How do you define the split.
We would hope not to have to define the split explicitly. Since we're
hotplugging memory and resizing zones anyway, it shouldn't be a real
functional problem to balance memory between the 2 states, no matter how
it is implemented.
> There are lots of circumstances where user
> pages can be pinned for a long (near indefinite) period of time and used
> for DMA.
For simple cases, anything tricky like DMA will simply be in an
unremovable area. However, some platforms like ppc64 logical
partitions, require firmware notification of DMA areas. The ppc64
firmware provides consistent remapping functionality for these DMA areas
if they ever need to be hot-swapped.
> Consider
> - Video capture
> - AGP Gart
> - AGP based framebuffer (intel i8/9xx)
> - O_DIRECT I/O
>
> There are also things like cluster interconnects, sendfile and the like
> involved here.
When we get to trying to forcefully migrate the kinds of memory that you
reference above, we'll likely need firmware support like ppc64 has. The
other option is to have some driver callbacks to tell them to reallocate
their buffers into new areas, if that's even possible. But, even that's
not something I see ever happening to the entire tree, more likely a
small subset of the drivers that really need it.
-- Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread