Re: xfs fails dbench in 2.6.18-rc1-mm1

[Keith Mannthey]

On 7/12/06, Badari Pulavarty <pbadari@xxxxxxxxxx> wrote:
> On Wed, 2006-07-12 at 13:26 -0700, Martin Bligh wrote:
> > Badari Pulavarty wrote:
> > > Martin Bligh wrote:
> > >
> > >> Eric Dumazet wrote:
> > >>
> > >>> On Wednesday 12 July 2006 18:58, Martin Bligh wrote:
> > >>>
> > >>>> http://test.kernel.org/abat/40891/debug/test.log.1
> > >>>>
> > >>>> Filesystem type for /mnt/tmp is xfs
> > >>>> write failed on handle 13786
> > >>>> 4 clients started
> > >>>> Child failed with status 1
> > >>>> write failed on handle 13786
> > >>>> write failed on handle 13786
> > >>>> write failed on handle 13786
> > >>>>
> > >>>> Works fine in -git4
> > >>>> All other fs's seemed to run OK.
> > >>>>
> > >>>> Machine is a 4x Opteron.
> > >>>
> > >>>
> > >>>
> > >>> You need to revert 92eb7a2f28d551acedeb5752263267a64b1f5ddf
> > >>
> > >>
> > >> Still fails (thanks Andy).
> > >>
> > > Wondering if its my changes :(
> > > Can you back out these and try ?
> > >
> > > Please, Please tell me that, its not me :)
> > >
> > > Thanks,
> > > Badari
> > >
> > > #
> > > vectorize-aio_read-aio_write-fileop-methods.patch
> > > remove-readv-writev-methods-and-use-aio_read-aio_write.patch
> > > streamline-generic_file_-interfaces-and-filemap.patch
> > > streamline-generic_file_-interfaces-and-filemap-ecryptfs.patch
> >
> > You could submit a job to elm3b6 to run dbench on xfs ;-)
> >
> > M.
>
>
> I am not able to "insmod xfs.ko" on my x86-64 machine :(
>
> elm3b29:~ # modprobe xfs
> FATAL: Error inserting xfs (/lib/modules/2.6.18-rc1-
> mm1/kernel/fs/xfs/xfs.ko): Cannot allocate memory
>
> #dmesg shows ..
>
> Could not allocate 8 bytes percpu data
> Could not allocate 8 bytes percpu data
> Could not allocate 8 bytes percpu data
> Could not allocate 8 bytes percpu data
> Could not allocate 8 bytes percpu data
> Could not allocate 8 bytes percpu data
> Could not allocate 328 bytes percpu data
> Could not allocate 328 bytes percpu data
> Could not allocate 328 bytes percpu data
>
>
> Whats happening here ?

The per-cpu area is exhausted in -mm x68_64 (If you pump up the percpu
area or cut down NR_CPUS you can work around it).  I ran into this a
few -mm release ago. There are some details in the 2.6.17-mm6 thread
from July 5th of so.

Thanks,
 Keith
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/