Re: Are these books outdated?

[Kosta Zertsekel]

Hey guys!
Let us remember that the most important thing regarding the Linux books -
is to read it!!
:-)
--- KostaZ

On Thu, Jul 14, 2016 at 5:44 PM, Rami Rosen  wrote:

> Hi Andrey,
>
> >Here is link to Jessica McKellar's (LDD4 co-author) repo with examples
> >for the next book.
> >https://github.com/jesstess/ldd4
>
> Thanks for the link, I was not aware of it !
>
> Rami Rosen
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: When to use threaded interrupts?

[Kosta Zertsekel]

>> On 10 September 2015 at 20:49, Kosta Zertsekel <zertse...@gmail.com>
>> Also, I see that in 4.2 there are only ~76 drivers that use threaded
>> interrupt:
>> ```
>> $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l
>> 76
>> ```

> On Sun, Sep 13, 2015 at 2:16 PM, Rami Rosen <roszenr...@gmail.com> wrote:
> This kernel and older ones include device drivers which use threaded IRQs
> (call request_threaded_irq(), etc).
> For example, many of the driver under drivers/input/touchscreen are
> using threaded IRQs:
> Following link is from kernel 3.18:
>
http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c?v=3.18
>
> How did you came to the conclusion that this kernel does not support
> threaded IRQs ? could it be that you simply do not use device drivers
> that use this mechanism ?

In the given touch screen driver request_threaded_irq() provides NULL
for the thread function pointer. Hence, the non-threaded IRQ mechanism
is actually being used.  This is why I grepped for IRQ_WAKE_THREAD and
not for request_threaded_irq.

So, the questions remains.
Why only ~76 drivers use the threaded IRQ mechanism?
What are the cons of the threaded IRQ mechanism?

Thanks,
--- KostaZ
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: When to use threaded interrupts?

[Kosta Zertsekel]

​>> I think I get the pro of using threaded interrupts - to decrease the
maximum
>> interrupt latency on RT workloads and/or RT machines (servers, embedded,
>> etc.).
​>> So, I'd like to ask:
>>- Why not **all** of the drivers use the threaded interrupts?
>>- What are the cons of the threaded interrupts?
>>
> Just a wild assumption: maybe the cost of incurring context switches ?
> (comparing to tasklets)

I get that threaded IRQ is better than softIrqs because threaded IRQ
supports
priorities. On the other hand, added context switches surely get system
slower.
But from the practical point of view - why on relatively new Intel PC there
are
no threaded irqs at all?

```
$ uname -a
Linux kostaz-OptiPlex-7010 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11
14:16:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
```

--- KostaZ

On Thu, Sep 10, 2015 at 11:09 PM, Rami Rosen <roszenr...@gmail.com> wrote:

> Kosta,
>
> ​​
> Just a wild assumption: maybe the cost of incurring context switches ?
> (comparing to tasklets)
>
> Best Regards,
> Rami Rosen
> http://ramirose.wix.com/ramirosen
>
>
>
> On 10 September 2015 at 20:49, Kosta Zertsekel <zertse...@gmail.com>
> wrote:
> > Hi guys,
> >
> > I hope I'm on right mailing list. :-)
> > I think I get the pro of using threaded interrupts - to decrease the
> maximum
> > interrupt latency on RT workloads and/or RT machines (servers, embedded,
> > etc.).
> >
> > Also, I see that in 4.2 there are only ~76 drivers that use threaded
> > interrupt:
> > ```
> > $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l
> > 76
> > ```
> >
> ​​
> > So, I'd like to ask:
> >- Why not **all** of the drivers use the threaded interrupts?
> >- What are the cons of the threaded interrupts?
> >
> > Thanks,
> > --- KostaZ
> >
> > ___
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

When to use threaded interrupts?

[Kosta Zertsekel]

Hi guys,

I hope I'm on right mailing list. :-)
I think I get the pro of using threaded interrupts - to decrease the maximum
interrupt latency on RT workloads and/or RT machines (servers, embedded,
etc.).

Also, I see that in 4.2 there are only ~76 drivers that use threaded
interrupt:
```
$ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l
76
```

​So, I'd like to ask:
   - Why not **all** of the drivers use the threaded interrupts?
   - What are the cons of the threaded interrupts?​

Thanks,
--- KostaZ
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: About interrupt handler

[Kosta Zertsekel]

On Fri, Feb 24, 2012 at 11:18 PM, Dave Hylands dhyla...@gmail.com wrote:
 HI Kosta,

 On Fri, Feb 24, 2012 at 1:08 PM, Dave Hylands dhyla...@gmail.com wrote:
 Hi Kosta,

 On Fri, Feb 24, 2012 at 1:19 AM, Kosta Zertsekel zertse...@gmail.com wrote:
 I'm begin to learn the Kernel and i'm reading Linux kernel
 development.It says This is an important point, always keep in mind 
 that
 all interrupt handler has interrupted other code(possibly even another
 interrupt handler on a different line).What i am not able to understand 
 is
 how a interrupt handler be interrupted ? DID NOT it uninterrupted?

 It depends on the architecture and the interrupt controller being
 used, and the driver code itself.

 Normally, when an interrupt fires, that particular interrupt will be
 masked and your own handler won't interrupt itself, but you may very
 well be interrupted by other interrupts.

 Can you please point out some code for explanation?

 Could you be a bit more specific about what example you're looking for?

 I also believe that things have changed (since I looked at this in any
 detail). It seems that interrupts are now run with other interrupts
 disabled.
 See: http://lwn.net/Articles/364583/ and look at the IRQF_DISABLED discussion.

Oh, yes, it seems it does as of kernel 3.3.0. But I fail to accept the
argument...
What happens for NAPI drivers stalling the kernel - *nobody* can
interrupt them...
Is there some reliable IRQ deep dive explanation - I need one just to
wrap my mind over the issue?
Thanks,
--- KostaZ

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: About interrupt handler

[Kosta Zertsekel]

 I'm begin to learn the Kernel and i'm reading Linux kernel
 development.It says This is an important point, always keep in mind that
 all interrupt handler has interrupted other code(possibly even another
 interrupt handler on a different line).What i am not able to understand is
 how a interrupt handler be interrupted ? DID NOT it uninterrupted?

 It depends on the architecture and the interrupt controller being
 used, and the driver code itself.

 Normally, when an interrupt fires, that particular interrupt will be
 masked and your own handler won't interrupt itself, but you may very
 well be interrupted by other interrupts.

Can you please point out some code for explanation?
--- KostaZ

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Semaphore

[Kosta Zertsekel]

On Fri, Feb 24, 2012 at 11:04 AM, Kristof Provost kris...@sigsegv.be wrote:
 On 2012-02-24 09:07:40 (+0200), Kosta Zertsekel zertse...@gmail.com wrote:
   Imagine a driver which only one app can use at a time (perhaps a serial
   port). The kernel will take a lock when the user space app open()s the
   device node and release it when it close()s.
   If the app segfaults in between the open() and close() the lock will
   still get released. The kernel always cleans up open files for stopped
   processes, regardless of how they stop. During this cleanup the kernel
   will close() the device node, and as a result the driver will release
   the lock.

 Can you please point to some code in Linux Kernel that does the job?

 In kernel/exit.c, look at do_exit(). It cleans up a process after it's
 terminated (for whatever reason).
 It does a lot of cleanup, but through exit_files() - put_files_struct()
 - close_files() it ends up iterating over all open file descriptors and
 closing them.
 What's done for each close depends on what the process had open. Normal
 files will just be closed, or a TCP socket might be closed, or if a
 device node was opened the corresponding drivers close() function will
 be called.

I meant that I don't see any semaphore related stuff in do_exit().
It seems that semaphore just remains there in the system after a user
land task is killed...

--- KostaZ

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: pagetables used in interrupt context

[Kosta Zertsekel]

 I am not familiar with other architecture, but for ARM, Linux Kernel
 2.6.35, i checked the function handle_level_irq()and handle_edge_irq() in
 chip.c, both of them will call handle_IRQ_event() which is in handle.c. and
 the function handle_IRQ_event() will call the interrupt handler written by
 user. Kernel does not open interrupt(ARM CPSR I bit)when calling interrupt
 handler in handle_IRQ_event() function. this is only for top-half interrupt
 handling.  for bottom-half, it is no doubt that the interrupt will be
 opened.

The same applies to 3.3.0 as I see from the code of handle_irq_event_percpu()
and its friends...
--- KostaZ

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Semaphore

[Kosta Zertsekel]

  Can you please point to some code in Linux Kernel that does the job?
 
  In kernel/exit.c, look at do_exit(). It cleans up a process after it's
  terminated (for whatever reason).
  It does a lot of cleanup, but through exit_files() - put_files_struct()
  - close_files() it ends up iterating over all open file descriptors and
  closing them.
  What's done for each close depends on what the process had open. Normal
  files will just be closed, or a TCP socket might be closed, or if a
  device node was opened the corresponding drivers close() function will
  be called.

 I meant that I don't see any semaphore related stuff in do_exit().
 It seems that semaphore just remains there in the system after a user
 land task is killed...

 In this (fictional, I've not looked at the serial driver code) example I'm
 assuming a semaphore owned by a driver. The user space application is using
 the driver through a device node. The semaphore is managed by the driver,
 and released when the close is called.
 The driver does not know how (or even if) the application stopped, only
 that it closed the file descriptor.

 What specific type of semaphore are you interested in? Who acquires it,
 what does it protect?

I think of user land program opening a socket and crashing on
segmentation fault.
In code 'socket' syscall does:
sock_map_fd -- sock_alloc_file -- alloc_file -- ... get lost ...
Where exactly in this case lock is held - I mean the lock that gets
released when user land process dies?
Thanks,
--- KostaZ

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Semaphore

[Kosta Zertsekel]

  Imagine a driver which only one app can use at a time (perhaps a serial
  port). The kernel will take a lock when the user space app open()s the
  device node and release it when it close()s.
  If the app segfaults in between the open() and close() the lock will
  still get released. The kernel always cleans up open files for stopped
  processes, regardless of how they stop. During this cleanup the kernel
  will close() the device node, and as a result the driver will release
  the lock.

Can you please point to some code in Linux Kernel that does the job?
Thanks,
--- KostaZ

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies