In any case I wish all accesses to struct vm_page are wrapped by
macros/functions. Hopefully FS modules always use functions so
that the structure can be opaque.
On Mon, Apr 04, 2011 at 02:17:44PM +, Andrew Doran wrote:
> On Mon, Apr 04, 2011 at 09:08:51AM +1000, matthew green wrote:
> >
> >
> :-) The trouble is large parts of the kernel are migrated to kmem
> already and having too interfaces and two allocators is something that
> needs cleanup. The malloc-type statistics would need a major overhaul
> if they are the way to go, what I doubt, as the essentially make
> malloc single th
On 04/03/11 14:52, Manuel Bouyer wrote:
> On Sun, Apr 03, 2011 at 02:36:37PM +0200, Lars Heidieker wrote:
>> On 04/03/11 01:36, Matthew Mondor wrote:
>>> On Sat, 2 Apr 2011 11:49:14 +0200
>>> Martin Husemann wrote:
>>>
On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
> AFAIK
> On Thu, Mar 31, 2011 at 03:53:22PM -0400, Thor Lancelot Simon wrote:
> >
> > 2) About 200 xfers/sec (about 3MB/sec worth) is still going on
> >to the SSD for much of the build process. It's all writes.
> >All build directories (obj, dest, tools, release) are on
> >a
On Mon, Apr 04, 2011 at 09:08:51AM +1000, matthew green wrote:
>
> > On Sun, Apr 03, 2011 at 07:35:04PM +1000, matthew green wrote:
> > >
> > > > Ignoring the free page allocator which abuses pg->offset, is there any
> > > > reason we cannot fold pg->flags into pg->offset? The lower PAGE_SHIFT
On Sun, 3 Apr 2011 19:17:28 +0300
Jukka Ruohonen wrote:
> While I have no real opinion for or against, I can certainly imagine
> finding use for a well-defined "bit function" like this also in user
> space.
Sure, I agree. We can still add such functions in for
userland programs, but for the ker
