linux-kernel - Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimiyxiKzT=9pKXLFACkc6C=nTD2dtBR7PcgjhOL@mail.gmail.com>
Date:	Fri, 3 Dec 2010 10:16:25 +0100
From:	Par-Gunnar Hjalmdahl <pghatwork@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linus.walleij@...ricsson.com, linux-bluetooth@...r.kernel.org,
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	Marcel Holtmann <marcel@...tmann.org>
Subject: Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.

2010/10/29 Alan Cox <alan@...rguk.ukuu.org.uk>:
>> The reason is that the work is generated so often that a work is not
>> finished before next work of same type comes. This is especially true
>> for transmit and receive. Then I get 0 back when queuing the work and
>> there is no real way to solve it from what I can see than to allocate
>> new work structures every time.
>
> So if that is the case what bounds your memory usage - can a busy box end
> up with thousands of work queue slos used ? It sounds like your model is
> perhaps wrong - if there is a continual stream of work maybe you should
> simply have a kernel thread to handle it if it cannot be deferred
> - remember ldisc code is able to sleep in most paths.
>
>

Hi Alan,

I went through my old mails here and realized I hadn't answered you
for this question.
Basically most of the time we are able to handle the works in time for
the next work to be created. But there are occasions where next work
is created really quickly and we end up with an error situation when
starting the work. But if we allocate the work it will then be handled
when the first one is ready. It's not like we will never handle it.
The data transfers can be received in a bit bursty way and then there
are no interrupts for a while. So in the end all works are handled
rather quickly and queue will never build up. We have tested with
several large file transfers and data pumps without issues.

By the way, I will soon release a new patch set for CG2900 (hopefully
next week), which contains major rework. It's hard to explain
everything here and now but changes include:
 - Reuse of existing HCI line discipline under /drivers/bluetooth/.
Line discipline has been modified so it is selectable from protocol if
line discipline should register to Bluetooth stack or not.
 - Architecture modification: core, chip, and transport is new created
from platform specific files (/arch/). Each chip file then spawns MFD
devices for the channels it support.
 - Core file now only handles detection of connected chip. All chip
dependent code is moved to transport and chip files.

/P-G
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/