Hi Frank and Matt,
For some odd reason, pthread_attr_setstacksize() fails on ppc with
EAGAIN. It should only fail with EINVAL if passed in value
WORK_POOL_STACK_SIZE doesn't pass some restrictions. Oddly, the macro
value is OFF by one for 16 byte alignment, but correcting it didn't seem
to help ei
Don't know about performance issues with high numbers, but the upper
bound value can be controlled by NOFILE in /etc/sysconfig/ganesha file.
commit 14447420966b9dfcdeb9975ac134a36613ade3c4
Author: Malahal Naineni
Date: Tue Mar 31 18:42:17 2015 -0500
Let ganesha use configurable number of
Hi Frank, Matt,
I remember we had the discussion of fd description limit but don't
remember the details.
First how do we control the limit of fd in Ganesha.
We see low performance when running with high number of open files, are
there known problems with fd management?
This is for NFSv3.
Thanks,
>From Matt Benjamin :
Matt Benjamin has uploaded a new change for review.
https://review.gerrithub.io/241876
Change subject: cache_inode: remove unused monster buf constant
..
cache_inode: remove unused monster buf constant
>From Matt Benjamin :
Matt Benjamin has uploaded a new change for review.
https://review.gerrithub.io/241873
Change subject: cache_inode_lru: shift object addr in lru_lane_of
..
cache_inode_lru: shift object addr in lru_lane_
>From Matt Benjamin :
Matt Benjamin has uploaded a new change for review.
https://review.gerrithub.io/241859
Change subject: cache_inode: improved lookup table tuning
..
cache_inode: improved lookup table tuning
1. raise max
Bill,
Please don't make this change. We can discuss tuning changes at your leisure.
Thanks,
Matt
- "William Allen Simpson" wrote:
> As I've been fixing the problem with ntirpc *_cleanup(), have
> discovered that it all passes through ntirpc svc_rqst.[ch].
>
> Trying to grok it, it's all
Addressing this (and the sequence we'll address it in) is already in the work
plan, right?
Matt
- "William Allen Simpson" wrote:
> Every time there's an event, the current code re-arms the fd
> from the epoll.
>
> That means 3 system calls for each incoming event. Hopefully,
> I'm not doi
Every time there's an event, the current code re-arms the fd
from the epoll.
That means 3 system calls for each incoming event. Hopefully,
I'm not doing it that way for RDMA events
What's the reason for re-arming? Also, EPOLLONESHOT?
