* dirty pages path in kernel
@ 2003-01-28 17:27 David Chow
2003-01-28 19:13 ` Andrew Morton
0 siblings, 1 reply; 5+ messages in thread
From: David Chow @ 2003-01-28 17:27 UTC (permalink / raw)
To: linux-mm
Hi,
If I do the following to an inode mapping page .
1. Generate a "struct page" from read_cache_page()
2. kmap() the page, do some memset() (Dirty the page)
3. kunmap() and page_cache_release() the page.
Since I didn't change any flags in the struct page, and I don't call to the corresponding commit_write() path. How is this page handled afterwards? Does the kernel will call its corresponding writepage() routine when unmap? Or it will ignore the dirty page as the kernel doesn't detects it. What will happen then? Will I loose any changes to that page data? I'm trying to implement some asynchronous mechasim on purging dirty pages on disk writes. Please give advice.
regards,
David
--
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: dirty pages path in kernel
2003-01-28 17:27 dirty pages path in kernel David Chow
@ 2003-01-28 19:13 ` Andrew Morton
2003-01-28 21:08 ` Andrew Morton
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2003-01-28 19:13 UTC (permalink / raw)
To: David Chow; +Cc: linux-mm
David Chow <davidchow@shaolinmicro.com> wrote:
>
> Hi,
>
> If I do the following to an inode mapping page .
>
> 1. Generate a "struct page" from read_cache_page()
> 2. kmap() the page, do some memset() (Dirty the page)
> 3. kunmap() and page_cache_release() the page.
>
The VFS does not know that the page has changed.
You should do:
lock_page(page);
memset()
set_page_dirty(page);
unlock_page(page);
the page will be written to disk on the next kupdate cycle.
--
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: dirty pages path in kernel
2003-01-28 19:13 ` Andrew Morton
@ 2003-01-28 21:08 ` Andrew Morton
2003-01-29 10:51 ` Nikita Danilov
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2003-01-28 21:08 UTC (permalink / raw)
To: David Chow, linux-mm
Andrew Morton wrote:
>
> David Chow <davidchow@shaolinmicro.com> wrote:
> >
> > Hi,
> >
> > If I do the following to an inode mapping page .
> >
> > 1. Generate a "struct page" from read_cache_page()
> > 2. kmap() the page, do some memset() (Dirty the page)
> > 3. kunmap() and page_cache_release() the page.
> >
>
> The VFS does not know that the page has changed.
>
> You should do:
>
> lock_page(page);
> memset()
> set_page_dirty(page);
> unlock_page(page);
>
> the page will be written to disk on the next kupdate cycle.
Make that:
lock_page(page);
kaddr = kmap_atomic(page, KM_USER0);
memset(kaddr, ...);
flush_dcache_page(page)
kunmap_atomic(kaddr, KM_USER0);
set_page_dirty(page);
unlock_page(page);
--
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: dirty pages path in kernel
2003-01-28 21:08 ` Andrew Morton
@ 2003-01-29 10:51 ` Nikita Danilov
2003-02-01 9:18 ` David Chow
0 siblings, 1 reply; 5+ messages in thread
From: Nikita Danilov @ 2003-01-29 10:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Chow, linux-mm
Andrew Morton writes:
> Andrew Morton wrote:
> >
> > David Chow <davidchow@shaolinmicro.com> wrote:
> > >
> > > Hi,
> > >
> > > If I do the following to an inode mapping page .
> > >
> > > 1. Generate a "struct page" from read_cache_page()
> > > 2. kmap() the page, do some memset() (Dirty the page)
> > > 3. kunmap() and page_cache_release() the page.
> > >
> >
> > The VFS does not know that the page has changed.
> >
> > You should do:
> >
> > lock_page(page);
> > memset()
> > set_page_dirty(page);
> > unlock_page(page);
> >
> > the page will be written to disk on the next kupdate cycle.
>
> Make that:
>
> lock_page(page);
> kaddr = kmap_atomic(page, KM_USER0);
> memset(kaddr, ...);
> flush_dcache_page(page)
> kunmap_atomic(kaddr, KM_USER0);
> set_page_dirty(page);
Shouldn't mark_page_accessed() go here?
> unlock_page(page);
Nikita.
--
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: dirty pages path in kernel
2003-01-29 10:51 ` Nikita Danilov
@ 2003-02-01 9:18 ` David Chow
0 siblings, 0 replies; 5+ messages in thread
From: David Chow @ 2003-02-01 9:18 UTC (permalink / raw)
To: Nikita; +Cc: akpm, davidchow, linux-mm
> Andrew Morton writes:
> > Andrew Morton wrote:
> > >
> > > David Chow <davidchow@shaolinmicro.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > If I do the following to an inode mapping page .
> > > >
> > > > 1. Generate a "struct page" from read_cache_page()
> > > > 2. kmap() the page, do some memset() (Dirty the page)
> > > > 3. kunmap() and page_cache_release() the page.
> > > >
> > >
> > > The VFS does not know that the page has changed.
> > >
> > > You should do:
> > >
> > > lock_page(page);
> > > memset()
> > > set_page_dirty(page);
> > > unlock_page(page);
> > >
> > > the page will be written to disk on the next kupdate cycle.
> >
> > Make that:
> >
> > lock_page(page);
> > kaddr = kmap_atomic(page, KM_USER0);
> > memset(kaddr, ...);
> > flush_dcache_page(page)
> > kunmap_atomic(kaddr, KM_USER0);
> > set_page_dirty(page);
>
> Shouldn't mark_page_accessed() go here?
>
> > unlock_page(page);
>
> Nikita.
Thanks for your help. However, do I have to deal with page ref cnts?
regards,
David
--
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-02-01 9:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-28 17:27 dirty pages path in kernel David Chow
2003-01-28 19:13 ` Andrew Morton
2003-01-28 21:08 ` Andrew Morton
2003-01-29 10:51 ` Nikita Danilov
2003-02-01 9:18 ` David Chow
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox