On Sun, 21 Oct 2007 12:39:30 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > On Sunday 21 October 2007 18:23, Eric W. Biederman wrote:
> >> Christian Borntraeger <[EMAIL PROTECTED]> writes:
> >
> >> Let me put it another way. Looking at /proc/sl
On Monday 22 October 2007 04:39, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > On Sunday 21 October 2007 18:23, Eric W. Biederman wrote:
> >> Christian Borntraeger <[EMAIL PROTECTED]> writes:
> >>
> >> Let me put it another way. Looking at /proc/slabinfo I can get
> >> 37
On Monday 22 October 2007 03:56, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > OK, I missed that you set the new inode's aops to the ramdisk_aops
> > rather than the bd_inode. Which doesn't make a lot of sense because
> > you just have a lot of useless aops there now.
>
> N
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Sunday 21 October 2007 18:23, Eric W. Biederman wrote:
>> Christian Borntraeger <[EMAIL PROTECTED]> writes:
>
>> Let me put it another way. Looking at /proc/slabinfo I can get
>> 37 buffer_heads per page. I can allocate 10% of memory in
>> buffer_head
Nick Piggin <[EMAIL PROTECTED]> writes:
> OK, I missed that you set the new inode's aops to the ramdisk_aops
> rather than the bd_inode. Which doesn't make a lot of sense because
> you just have a lot of useless aops there now.
Not totally useless as you have mentioned they are accessed by
the lr
On Sunday 21 October 2007 18:23, Eric W. Biederman wrote:
> Christian Borntraeger <[EMAIL PROTECTED]> writes:
> Let me put it another way. Looking at /proc/slabinfo I can get
> 37 buffer_heads per page. I can allocate 10% of memory in
> buffer_heads before we start to reclaim them. So it requir
On Sunday 21 October 2007 16:48, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > Yes it does. It is exactly breaking the coherency between block
> > device and filesystem metadata coherency that Andrew cared about.
> > Whether or not that matters, that is a much bigger concep
Christian Borntraeger <[EMAIL PROTECTED]> writes:
> Am Sonntag, 21. Oktober 2007 schrieb Eric W. Biederman:
>> Nick. Reread the patch. The only thing your arguments have
>> established for me is that this patch is not obviously correct. Which
>> makes it ineligible for a back port. Frankly I s
Am Sonntag, 21. Oktober 2007 schrieb Eric W. Biederman:
> Nick. Reread the patch. The only thing your arguments have
> established for me is that this patch is not obviously correct. Which
> makes it ineligible for a back port. Frankly I suspect the whole
> issue is to subtle and rare to make a
Nick Piggin <[EMAIL PROTECTED]> writes:
> Yes it does. It is exactly breaking the coherency between block
> device and filesystem metadata coherency that Andrew cared about.
> Whether or not that matters, that is a much bigger conceptual
> change than simply using slightly more (reclaimable) memor
On Sunday 21 October 2007 15:10, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > On Saturday 20 October 2007 08:51, Eric W. Biederman wrote:
> >> Currently the ramdisk tries to keep the block device page cache pages
> >> from being marked clean and dropped from memory. That
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Saturday 20 October 2007 08:51, Eric W. Biederman wrote:
>> Currently the ramdisk tries to keep the block device page cache pages
>> from being marked clean and dropped from memory. That fails for
>> filesystems that use the buffer cache because the bu
On Saturday 20 October 2007 08:51, Eric W. Biederman wrote:
> Currently the ramdisk tries to keep the block device page cache pages
> from being marked clean and dropped from memory. That fails for
> filesystems that use the buffer cache because the buffer cache is not
> an ordinary buffer cache u
13 matches
Mail list logo
