RE: [Dazuko-devel] __d_path export and SMP safeness

[Tushar]

On Wed, 2005-09-07 at 14:31, Tikka, Sami wrote:
> >-----Original Message-----
> >From: John Ogness [mailto:address@hidden 
> >Sent: Tuesday, September 06, 2005 5:46 PM
> >To: Tikka, Sami
> >Cc: address@hidden
> >Subject: Re: [Dazuko-devel] __d_path export and SMP safeness
> >
> >Well, this would double the amount of user/kernel switches, 
> >which would be a performance hit. It would also require that 
> >the /proc system is available.
> 
> Yes. Increased number of context switches is a problem, but as I see it,
> building a custom kernel is an even bigger problem. Customers are not happy
> with that.
Why there is multiple context switches?  I will like to know more about
it.
> 
> All the Linux 2.6 distros I have access at the moment (Novell Linux Desktop
> 9, SUSE Linux 9.3, SUSE Linux 9.2, SUSE Linux 9.1, SUSE Linux Enterprise
> Server 9, Red Hat Enterprise Linux 4, Mandrake 10.1) have /proc available.
> 
> Actually, the SUSE kernels have __d_path exported :) Perhaps Dazuko's
> configure script could check if __d_path is exported and then configure the
> driver so that this hack isn't necessary?
> 
> >If I were to implement this for Linux 2.6 SMP (the only 
> >affected kernels), then I would change Dazuko to send a 
> >filename without the beginning "/" for files in chroot'd 
> >environments. This would signal the user application that it 
> >needed to do a lookup for the full path. This would reduce the 
> >extra overhead to *only* file accesses in a chroot environment.
> 
As /proc is dynamically generated, it would be great if somehow we can
manage to get the root entry in kernel space itself and return final
path to user. This way, we can keep semantics of filename field same for
all process. Please let me know what u people think about this.

Thanks.
> Yess... Cool.
> 
> Thanks,
> 
> -- Sami
> 
> 
> _______________________________________________
> Dazuko-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/dazuko-devel
-- 
Regards,
Tushar
--------------------
It's not a problem, it's an opportunity for improvement. Lets improve.