NFS version4 maximum on-the-wire data size.
Hi, I am unable to get the exact count for the amount of on-the-wire data size that NFSv4 supports. I could get exact figures in case of NFSv3 (http://nfs.sourceforge.net). It's 60KB when NFSv3 is used over UDP and implementation dependent in case it is used over TCP. Any idea about NFSv4 statistics? Any pointers would be appreciated. -- Thanks, Nilesh -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
A question
Process context is schedulable but interrupt context is not. Why and how? Any examples I can look at? Thanks. -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
RE: A question
-Original Message- From: kernelnewbies-bou...@nl.linux.org [mailto:kernelnewbies- bou...@nl.linux.org] On Behalf Of Hiren Panchasara Sent: Wednesday, September 01, 2010 9:08 PM To: kernelnewbies@nl.linux.org Subject: A question Process context is schedulable but interrupt context is not. Why and how? Interrupt line can be shared by multiple interrupts or to avoid delay in handling subsequent interrupts on single line - the handler has to be quick enough. So we avoid scheduling out or sleeping inside the interrupt handlers. Any examples I can look at? -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: A question
On 9/1/2010 9:45 PM, Tayade, Nilesh wrote: -Original Message- From: kernelnewbies-bou...@nl.linux.org [mailto:kernelnewbies- bou...@nl.linux.org] On Behalf Of Hiren Panchasara Sent: Wednesday, September 01, 2010 9:08 PM To: kernelnewbies@nl.linux.org Subject: A question Process context is schedulable but interrupt context is not. Why and how? Interrupt line can be shared by multiple interrupts or to avoid delay in handling subsequent interrupts on single line - the handler has to be quick enough. So we avoid scheduling out or sleeping inside the interrupt handlers. Adding... Scheduling blocks. And if interrupt handler is blocked ( scheduled ) it will lead to freeze. Thanks. Any examples I can look at? -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: A question
I had read an article[1] a while back about a push in the real-time kernel branch to make interrupt handlers scheduleable, but the article also does a good job of explaining the context of interrupt handlers currently. I do not know the state of this, but at the time found it interesting. [1]http://lwn.net/Articles/302043/ -- John -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: A question
Interrupt context is a loaded term. It is used for both top-half and bottom-half processing. Linux defines two terms in the top-half, one is Interrupt handler (IH) and Interrupt Service Routine (ISR). Interrupt handler is a standard kernel code that is executed by the processor once the interrupt is generated. To abstract it, this generic code is executed for all the generated interrupts. This, in general saves the present processor context and paves way for the execution of ISR. ISR is a interrupt service routine written by a device driver programmer to handle the interrupt of a device. ISR is mainly responsible to verify the status register of a device to find out the cause of the interrupt and act accordingly. Both IH and ISR will not have a context of its own. Interrupts generated by a hardware device is asynchronous. i.e. it can be generated at any point in time. When such a interrupt is generated, the current execution is interrupted and the execution control is transferred to IH and ISR will be executed. Thus we can infer that both IH and ISR will be executing in an anonymous context. For Eg. Consider there are 3 tasks T2, T3. Suppose T2 invoked a read system call to read data from the secondary media (say hard disk), driver of the hard disk will initiate the device to gather the data and put task T2 in the wait queue and invokes scheduler. Now, scheduler picks up say T3. When processor is executing task T3, there was interrupt generated by the harddisk controller indicating that data is ready. At this point IH and ISR is executed. IH and ISR of this interrupt has no relevance to task T3, but still it is executed in the context of T3. Hence we say that IH and ISR will always be executed in the anonymous context. Most of the bottom half execution happens the same way, i.e. it will be executing in the anonymous context unless the job of bottom half is relegated to respective kernel threads. In the latter case the bottom half execution will have its own context. For more details about top-half and bottom half, refer ULK 3rd edtion by Bovet, Chapter 4 Regards, Prabhu On Wed, Sep 1, 2010 at 9:08 PM, Hiren Panchasara hiren.panchas...@gmail.com wrote: Process context is schedulable but interrupt context is not. Why and how? Any examples I can look at? Thanks. -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
