On Fri, 4 Feb 2005, Anton Altaparmakov wrote:
> On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
> >
> > I think the point is that we can't have a "handler for writes," because
> > the writes are being done by simple CPU Store instructions in a user
> > program. The handler we're
On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
> >> > > And for the vmscan->writepage() side of things I wonder if it would
> be
> >> > > possible to overload the mapping's ->nopage handler. If the target
> page
> >> > > lies in a hole, go off and allocate all the necessary pagecache
On Fri, 4 Feb 2005, Anton Altaparmakov wrote:
On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
I think the point is that we can't have a handler for writes, because
the writes are being done by simple CPU Store instructions in a user
program. The handler we're talking about
On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
And for the vmscan-writepage() side of things I wonder if it would
be
possible to overload the mapping's -nopage handler. If the target
page
lies in a hole, go off and allocate all the necessary pagecache
pages, zero
>> > > And for the vmscan->writepage() side of things I wonder if it would
be
>> > > possible to overload the mapping's ->nopage handler. If the target
page
>> > > lies in a hole, go off and allocate all the necessary pagecache
pages, zero
>> > > them, mark them dirty?
>> >
>> > I guess it
And for the vmscan-writepage() side of things I wonder if it would
be
possible to overload the mapping's -nopage handler. If the target
page
lies in a hole, go off and allocate all the necessary pagecache
pages, zero
them, mark them dirty?
I guess it would be possible but
6 matches
Mail list logo
