I'm getting the error "VFS: file-max limit 50905 reached" on kernels 2.6.14 and
2.6.15, running on a qemu virtual machine configured with 512 MB of memory. The
error occurs when I build a relatively large C++ program (the Boost library) on
the VM (which is otherwise idle). It does not occur on kernels 2.6.11 or 2.6.13.
I understand that changes have been made recently to the way the kernel manages
file descriptors in order to improve real-time performance.
A thread back in October discussing these changes (subject: "VFS: file-max limit
50044 reached") seems to indicate that bad things can happen if certain
callbacks don't get called at regular intervals. This situation seems quite
likely in a virtual machine environment where the frequency of timer interrupts
might vary by orders of magnitude depending on the workload of the host machine.
I have attempted a few workarounds, to no avail:
* increasing file-max (echo 100000 >/proc/sys/fs/file-max)
* setting clock=pit kernel parameter
* setting rcupdate.maxbatch=1000000 kernel parameter
Is there some other way to make the kernel less sensitive to ill-behaved
hardware timers, as it was pre-2.6.14, assuming that I am willing to sacrifice
real-time performance?
Any help would be appreciated.
On Thu, Jan 19, 2006 at 04:19:24AM +0000, Ed Swierk wrote:
> I'm getting the error "VFS: file-max limit 50905 reached" on kernels 2.6.14 and
> 2.6.15, running on a qemu virtual machine configured with 512 MB of memory. The
> I understand that changes have been made recently to the way the kernel manages
> file descriptors in order to improve real-time performance.
The file descriptor changes were done to make lookup in the fd table
lock-free there by improving thread scalability.
> Is there some other way to make the kernel less sensitive to ill-behaved
> hardware timers, as it was pre-2.6.14, assuming that I am willing to sacrifice
> real-time performance?
>
> Any help would be appreciated.
Can you try this patch I posted a while ago -
http://marc.theaimsgroup.com/?l=linux-kernel&m=113657112726596&w=2
Thanks
Dipankar