On Mon, Apr 27, 2015 at 03:14:49PM -0700, Linus Torvalds wrote:
> On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds
> wrote:
> >
> > IOW, all the people who say that it's about avoiding context switches
> > are probably just full of shit. It's not about context switches, it's
> > about bad user-leve
2015-04-30 22:52 GMT+08:00 Łukasz Stelmach :
> It was <2015-04-30 czw 14:45>, when Richard Weinberger wrote:
>> Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
>>> It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
> It was <2015-0
On Mon, 27 Apr 2015 15:14:49 -0700
Linus Torvalds wrote:
> On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds
> wrote:
> >
> > IOW, all the people who say that it's about avoiding context
> > switches are probably just full of shit. It's not about context
> > switches, it's about bad user-level cod
On Mon, 22 Jun 2015, Jindrich Makovicka wrote:
> >> IOW, all the people who say that it's about avoiding context switches
> >> are probably just full of shit. It's not about context switches, it's
> >> about bad user-level code.
> >
> > Just to make sure, I did a system-wide profile (so that you
On Mon, 27 Apr 2015 15:14:49 -0700, Linus Torvalds wrote:
> On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds
> wrote:
>>
>> IOW, all the people who say that it's about avoiding context switches
>> are probably just full of shit. It's not about context switches, it's
>> about bad user-level code.
>
On Fri, May 1, 2015 at 9:48 PM, Andy Lutomirski wrote:
> Havoc, am I missing something here? If I'm right about this aspect of
> D-Bus, then I'm a bit surprised.
>
I'm not well-informed about Binder, though from reading about it, it
seems to be modeled on and comparable to COM.
>From what I can
On Mon, Apr 27, 2015 at 9:33 AM, David Herrmann wrote:
> On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski wrote:
>> 2. This is a nice thought, but it doesn't work in practice. Sorry.
>> I can give you a big pile of CVEs from last year if you like, or I can
>> try explaining again.
>>
>> The iss
On 2015-04-29 08:47, Harald Hoyer wrote:
Until then the whole common IPC problem is unresolved and Linux
distributions are just a collection of random software with no common
interoperability and home grown interfaces.
I don't know how I managed to not notice this comment before, but I find
it p
On April 29, 2015 7:47:53 AM CDT, Harald Hoyer wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>On 29.04.2015 01:12, John Stoffel wrote:
>> LDAP is pretty damn generic, in that you can put pretty large objects
>into
>> it, and pretty large OUs, etc. So why would it be a candidate for
Am 30.04.2015 um 16:52 schrieb Łukasz Stelmach:
>> Sorry, I thought you mean the races while collecting metadata in userspace...
>
> My bad, some reace conditions *are* associated with collecting metadata
> but ont all. It is impossible (correct me if I am wrong) to implement
> reliable die-on-idl
It was <2015-04-30 czw 14:45>, when Richard Weinberger wrote:
> Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
>> It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
>>> Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
>>>
Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
> It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
>> Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
>>> It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
> It was <201
It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
> Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
>> It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
>>> Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
>>>
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
> It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
>> Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
>>> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
> Regardless,
It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
> Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
>> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
>>> Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
Regardless, of initrd issues I feel there is a need of a local IP
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
>> Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
>>> Regardless, of initrd issues I feel there is a need of a local IPC
>>> that is more capable than UDS. Linus Torvalds is probably rig
It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
> Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
>> Regardless, of initrd issues I feel there is a need of a local IPC
>> that is more capable than UDS. Linus Torvalds is probably right that
>> dbus-daemon is everything but effictient.
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
> Regardless, of initrd issues I feel there is a need of a local IPC that
> is more capable than UDS. Linus Torvalds is probably right that
> dbus-daemon is everything but effictient. I disagree, however, that it
> can be optimised and therefore solve
It was <2015-04-29 śro 17:21>, when Austin S Hemmelgarn wrote:
> On 2015-04-29 11:03, Theodore Ts'o wrote:
>> On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote:
>>> Sure, I can write one binary to rule them all, pull out all the code from
>>> all
>>> tools I need, but for me an IPC mech
> "David" == David Herrmann writes:
David> Hi
David> On Wed, Apr 29, 2015 at 10:43 PM, David Lang wrote:
>> If the justification for why this needs to be in the kernel is that you
>> can't reliably prevent apps from exiting if there are pending messages, [...]
David> It's not.
>> the answe
>>>
>>> I've had Enterprise systems where I could hit power on two boxes, and
>>> finish
>>> the OS install on one before the other has even finished POST and look
>>> for
>>> the boot media. I did this 5 years ago, before the "let's speed up boot"
>>> push started.
>>>
>>> Admittedly, this wasn't
On Thu, 30 Apr 2015, Dave Airlie wrote:
On 30 April 2015 at 10:05, David Lang wrote:
On Wed, 29 Apr 2015, Theodore Ts'o wrote:
On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
If your customers wnat this feature, you're more than welcome to fork
the kernel and support it yours
On 30 April 2015 at 10:05, David Lang wrote:
> On Wed, 29 Apr 2015, Theodore Ts'o wrote:
>
>> On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
>>>
>>> If your customers wnat this feature, you're more than welcome to fork
>>> the kernel and support it yourself. Oh wait... Redhat does
On Wed, 29 Apr 2015, Theodore Ts'o wrote:
On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
If your customers wnat this feature, you're more than welcome to fork
the kernel and support it yourself. Oh wait... Redhat does that
already. So what's the problem? Just put it into RHEL
On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
> If your customers wnat this feature, you're more than welcome to fork
> the kernel and support it yourself. Oh wait... Redhat does that
> already. So what's the problem? Just put it into RHEL (which I use
> I admit, along with Debi
> "Austin" == Austin S Hemmelgarn writes:
Austin> On 2015-04-29 14:54, Andy Lutomirski wrote:
>> On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
>>>
>>> * Being in the kernel closes a lot of races which can't be fixed with
>>> the current userspace solutions. For example, with kdbus, there
On Fri, Apr 24, 2015 at 4:08 AM, Karol Lewandowski
wrote:
> On Thu, Apr 23, 2015 at 09:30:13PM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Apr 23, 2015 at 01:42:25PM -0400, Stephen Smalley wrote:
>> > On 04/23/2015 01:16 PM, Greg Kroah-Hartman wrote:
>> > > The binder developers at Samsung have st
Hi
On Wed, Apr 29, 2015 at 10:43 PM, David Lang wrote:
> If the justification for why this needs to be in the kernel is that you
> can't reliably prevent apps from exiting if there are pending messages, [...]
It's not.
> the answer of "preventing apps from exiting if there are pending messages
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 1:15 PM, David Lang wrote:
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
wrote:
On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, "Harald Hoyer" w
On Wed, Apr 29, 2015 at 1:15 PM, David Lang wrote:
> On Wed, 29 Apr 2015, Andy Lutomirski wrote:
>
>> On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
>> wrote:
>>>
>>> On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
>
>
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
wrote:
On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
* Being in the kernel closes a lot of races which can't be fixed with
the current user
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
wrote:
> On 2015-04-29 14:54, Andy Lutomirski wrote:
>>
>> On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
>>>
>>>
>>> * Being in the kernel closes a lot of races which can't be fixed with
>>> the current userspace solutions. For example
On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
* Being in the kernel closes a lot of races which can't be fixed with
the current userspace solutions. For example, with kdbus, there is a
way a client can disconnect from a bus, but do so onl
> "Steven" == Steven Rostedt writes:
Steven> On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
>>
>> If your customers wnat this feature, you're more than welcome to fork
>> the kernel and support it yourself. Oh wait... Redhat does that
>> already. So what's the problem? Jus
Am Mittwoch, 29. April 2015, 13:39:42 schrieb Steven Rostedt:
> On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
> > If your customers wnat this feature, you're more than welcome to fork
> > the kernel and support it yourself. Oh wait... Redhat does that
> > already. So what's the pr
On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
> Of course this can all be done, but it would involve fallback mechanisms,
> which we want to get rid off. Hopefully, you don't suggest to merge dbus with
> PID 1. Also with a daemon, you will lose the points mentioned in the cover
> mail
> :
>
> *
Am Mittwoch, 29. April 2015, 17:22:08 schrieb Harald Hoyer:
> On 29.04.2015 17:17, Austin S Hemmelgarn wrote:
> > On 2015-04-29 11:07, Harald Hoyer wrote:
> >> Most of the stuff does not work without udev and something like
> >> systemd.>
> > That's funny, apparently the initramfs images I've been
On 04/29/2015 11:18 AM, Simon McVittie wrote:
> On 29/04/15 14:35, Stephen Smalley wrote:
>> It is also interesting that kdbus allows impersonation of any
>> credential, including security label, by "privileged" clients, where
>> privileged simply means it either has CAP_IPC_OWNER or owns (euid
>>
On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
>
> If your customers wnat this feature, you're more than welcome to fork
> the kernel and support it yourself. Oh wait... Redhat does that
> already. So what's the problem? Just put it into RHEL (which I use
> I admit, along with D
On Mon 27-04-15 13:11:03, Andy Lutomirski wrote:
> [resent without HTML]
>
> On Apr 27, 2015 5:46 AM, "Michal Hocko" wrote:
> >
> > On Wed 22-04-15 12:36:12, Andy Lutomirski wrote:
[...]
> > > The receiver gets to mmap the buffer. I'm not sure what protection they
> > > get.
> >
> > OK, so I've
On Wed, 29 Apr 2015, Martin Steigerwald wrote:
Am Mittwoch, 29. April 2015, 14:47:53 schrieb Harald Hoyer:
We really don't want the IPC mechanism to be in a flux state. All tools
have to fallback to a non-standard mechanism in that case.
If I have to pull in a dbus daemon in the initramfs, we
> "Harald" == Harald Hoyer writes:
Harald> On 29.04.2015 15:33, Richard Weinberger wrote:
>> It depends how you define "beginning". To me an initramfs is a *very* minimal
>> tool to prepare the rootfs and nothing more (no udev, no systemd, no
>> "mini distro").
>> If the initramfs fails to do
Am Mittwoch, 29. April 2015, 11:03:41 schrieb Theodore Ts'o:
> On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote:
> > Sure, I can write one binary to rule them all, pull out all the code
> > from all tools I need, but for me an IPC mechanism sounds a lot
> > better. And it should be _one
On 2015-04-29 11:22, Harald Hoyer wrote:
On 29.04.2015 17:17, Austin S Hemmelgarn wrote:
On 2015-04-29 11:07, Harald Hoyer wrote:
Most of the stuff does not work without udev and something like systemd.
That's funny, apparently the initramfs images I've been using for multiple
months now on s
Am Mittwoch, 29. April 2015, 14:47:53 schrieb Harald Hoyer:
> We really don't want the IPC mechanism to be in a flux state. All tools
> have to fallback to a non-standard mechanism in that case.
>
> If I have to pull in a dbus daemon in the initramfs, we still have the
> chicken and egg problem fo
On 29.04.2015 17:17, Austin S Hemmelgarn wrote:
> On 2015-04-29 11:07, Harald Hoyer wrote:
>> Most of the stuff does not work without udev and something like systemd.
>>
> That's funny, apparently the initramfs images I've been using for multiple
> months now on server systems at work which don't h
On 2015-04-29 11:03, Theodore Ts'o wrote:
On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote:
Sure, I can write one binary to rule them all, pull out all the code from all
tools I need, but for me an IPC mechanism sounds a lot better. And it should be
_one_ common IPC mechanism and not
On 2015-04-29 11:07, Harald Hoyer wrote:
Most of the stuff does not work without udev and something like systemd.
That's funny, apparently the initramfs images I've been using for
multiple months now on server systems at work which don't have systemd,
udev, or dbus, and do LVM/RAID assembly, n
On 29/04/15 14:35, Stephen Smalley wrote:
> As it currently stands, there
> are no LSM hook calls in the kdbus tree beyond metadata collection of
> security labels.
SELinux and AppArmor are the two particularly interesting LSMs here:
those are the ones that have support for user-space mediation in
On 29.04.2015 16:46, Austin S Hemmelgarn wrote:
> On 2015-04-29 10:11, Harald Hoyer wrote:
>> On 29.04.2015 16:04, Richard Weinberger wrote:
>>> Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
> Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
>>
On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote:
> Sure, I can write one binary to rule them all, pull out all the code from all
> tools I need, but for me an IPC mechanism sounds a lot better. And it should
> be
> _one_ common IPC mechanism and not a plethora of them. It should feel
Am 29.04.2015 um 16:53 schrieb Harald Hoyer:
> On 29.04.2015 16:18, Richard Weinberger wrote:
>> Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
> We don't handcraft the initramfs script for every our customers,
> therefore we
> have to generically support hotplug, persistent device names
On 29.04.2015 16:18, Richard Weinberger wrote:
> Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
We don't handcraft the initramfs script for every our customers, therefore
we
have to generically support hotplug, persistent device names, persistent
interface names, network connecti
Am 29.04.2015 um 16:46 schrieb Austin S Hemmelgarn:
> On 2015-04-29 10:11, Harald Hoyer wrote:
>> On 29.04.2015 16:04, Richard Weinberger wrote:
>>> Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
> Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
>>
On 2015-04-29 10:11, Harald Hoyer wrote:
On 29.04.2015 16:04, Richard Weinberger wrote:
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you d
Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
>>> We don't handcraft the initramfs script for every our customers, therefore
>>> we
>>> have to generically support hotplug, persistent device names, persistent
>>> interface names, network connectivity in the initramfs, user input handling
>>> for
>
On 29.04.2015 16:04, Richard Weinberger wrote:
> Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
>> On 29.04.2015 15:46, Richard Weinberger wrote:
>>> Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
> It depends how you define "beginning". To me an
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
> On 29.04.2015 15:46, Richard Weinberger wrote:
>> Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
>>> On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define "beginning". To me an initramfs is a *very*
minimal
tool to prep
On 29.04.2015 15:46, Richard Weinberger wrote:
> Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
>> On 29.04.2015 15:33, Richard Weinberger wrote:
>>> It depends how you define "beginning". To me an initramfs is a *very*
>>> minimal
>>> tool to prepare the rootfs and nothing more (no udev, no systemd
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
> On 29.04.2015 15:33, Richard Weinberger wrote:
>> It depends how you define "beginning". To me an initramfs is a *very* minimal
>> tool to prepare the rootfs and nothing more (no udev, no systemd, no
>> "mini distro").
>> If the initramfs fails to do i
On 29.04.2015 15:33, Richard Weinberger wrote:
> It depends how you define "beginning". To me an initramfs is a *very* minimal
> tool to prepare the rootfs and nothing more (no udev, no systemd, no
> "mini distro").
> If the initramfs fails to do its job it can print to the console like
> the kerne
On 04/29/2015 08:47 AM, Harald Hoyer wrote:
> On 29.04.2015 01:12, John Stoffel wrote:
>> LDAP is pretty damn generic, in that you can put pretty large objects into
>> it, and pretty large OUs, etc. So why would it be a candidate for going
>> into the kernel? And why is kdbus so important in the
On Wed, Apr 29, 2015 at 2:47 PM, Harald Hoyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 29.04.2015 01:12, John Stoffel wrote:
>> LDAP is pretty damn generic, in that you can put pretty large objects into
>> it, and pretty large OUs, etc. So why would it be a candidate for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29.04.2015 01:12, John Stoffel wrote:
> LDAP is pretty damn generic, in that you can put pretty large objects into
> it, and pretty large OUs, etc. So why would it be a candidate for going
> into the kernel? And why is kdbus so important in the
On 29.04.2015 01:12, John Stoffel wrote:
>> "Havoc" == Havoc Pennington writes:
>
> Havoc> On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote:
>>> I find dbus to be extremely hard to debug when my desktop starts doing
>>> things I don't want it to do. The fact that it might be flinging ar
On Tue, Apr 28, 2015 at 7:12 PM, John Stoffel wrote:
> Havoc> Yeah. I don't know how you answer that, because the answer is
> Havoc> probably "it would be good enough for some things and not for
> Havoc> other things." It depends on whether an app is sending enough
> Havoc> data to be too slow, an
On Tue, Apr 28, 2015 at 4:38 PM, Linus Torvalds
wrote:
> On Tue, Apr 28, 2015 at 4:23 PM, Andy Lutomirski wrote:
>>
>> I think we can do it without that by keeping the mapping in reverse as
>> I sort of outlined -- for each cpu, store a mapping from mm to pcid.
>> When things fall out of the list
On Tue, Apr 28, 2015 at 4:23 PM, Andy Lutomirski wrote:
>
> I think we can do it without that by keeping the mapping in reverse as
> I sort of outlined -- for each cpu, store a mapping from mm to pcid.
> When things fall out of the list, no big deal.
So you do it by just having a per-cpu array of
On Tue, Apr 28, 2015 at 4:16 PM, Linus Torvalds
wrote:
> On Tue, Apr 28, 2015 at 3:54 PM, Andy Lutomirski wrote:
>>
>> I had a totally different implementation idea in mind. It goes
>> something like this:
>>
>> For each CPU, we allocate a fixed number of PCIDs, e.g. 0-7. We have
>> a per-cpu a
On Tue, Apr 28, 2015 at 4:01 PM, Andy Lutomirski wrote:
>
> The reason I thought of PCIDs this way is that 12 bits isn't nearly
> enough to get away with allocating each mm its own PCID.
Not even close. And really, we've already done this for other
architectures. On alpha, the number of bits in t
On Tue, Apr 28, 2015 at 3:54 PM, Andy Lutomirski wrote:
>
> I had a totally different implementation idea in mind. It goes
> something like this:
>
> For each CPU, we allocate a fixed number of PCIDs, e.g. 0-7. We have
> a per-cpu array of the mm [1] that owns each PCID. [...]
We've done this b
> "Havoc" == Havoc Pennington writes:
Havoc> On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote:
>> So the question is if one of the justifications for moving the daemon
>> into kernel space is that it's performance is crap, then I think it is
>> useful to determine whether a fully optimiz
On Tue, Apr 28, 2015 at 3:56 PM, Rik van Riel wrote:
> On 04/28/2015 06:54 PM, Andy Lutomirski wrote:
>> On Tue, Apr 28, 2015 at 3:41 PM, Rik van Riel wrote:
>>> On 04/28/2015 06:15 PM, Kirill A. Shutemov wrote:
On Tue, Apr 28, 2015 at 01:42:10PM -0700, Andy Lutomirski wrote:
> At some p
On Tue, Apr 28, 2015 at 3:15 PM, Kirill A. Shutemov
wrote:
>
> I talked with Dave about implementing PCID and he thinks that it will be
> net loss.
So I'm told that Suresh Siddha actually had a patch inside Intel to
use PCID (back when he worked for Intel, I think he left), and that it
was a wash
On 04/28/2015 06:54 PM, Andy Lutomirski wrote:
> On Tue, Apr 28, 2015 at 3:41 PM, Rik van Riel wrote:
>> On 04/28/2015 06:15 PM, Kirill A. Shutemov wrote:
>>> On Tue, Apr 28, 2015 at 01:42:10PM -0700, Andy Lutomirski wrote:
At some point, I'd like to implement PCID on x86 (if no one beats me
On Tue, Apr 28, 2015 at 3:41 PM, Rik van Riel wrote:
> On 04/28/2015 06:15 PM, Kirill A. Shutemov wrote:
>> On Tue, Apr 28, 2015 at 01:42:10PM -0700, Andy Lutomirski wrote:
>>> At some point, I'd like to implement PCID on x86 (if no one beats me
>>> to it, and this is a low priority for me), which
On 04/28/2015 06:15 PM, Kirill A. Shutemov wrote:
> On Tue, Apr 28, 2015 at 01:42:10PM -0700, Andy Lutomirski wrote:
>> At some point, I'd like to implement PCID on x86 (if no one beats me
>> to it, and this is a low priority for me), which will allow us to skip
>> expensive TLB flushes while conte
On 04/28/2015 03:15 PM, Kirill A. Shutemov wrote:
> On Tue, Apr 28, 2015 at 01:42:10PM -0700, Andy Lutomirski wrote:
>> At some point, I'd like to implement PCID on x86 (if no one beats me
>> to it, and this is a low priority for me), which will allow us to skip
>> expensive TLB flushes while conte
On Tue, Apr 28, 2015 at 01:42:10PM -0700, Andy Lutomirski wrote:
> At some point, I'd like to implement PCID on x86 (if no one beats me
> to it, and this is a low priority for me), which will allow us to skip
> expensive TLB flushes while context switching. I have no idea whether
> ARM can do some
On Tue, Apr 28, 2015 at 12:19 PM, Havoc Pennington wrote:
>
> From what I can tell, the core performance claim for kdbus is that for
> a userspace daemon to be a routing intermediary, it has to receive and
> re-send messages. If the baseline performance of IPC is the cost to
> send once and receiv
On Tue, Apr 28, 2015 at 1:34 PM, David Lang wrote:
> On Tue, 28 Apr 2015, Havoc Pennington wrote:
>
>> On Tue, Apr 28, 2015 at 1:19 PM, David Lang wrote:
>>>
>>> If the examples that are being used to show the performance advantage of
>>> kdbus vs normal dbus are doing the wrong thing, then we ne
On Tue, 28 Apr 2015, Havoc Pennington wrote:
On Tue, Apr 28, 2015 at 1:19 PM, David Lang wrote:
If the examples that are being used to show the performance advantage of
kdbus vs normal dbus are doing the wrong thing, then we need to get some
other examples available to people who don't live an
On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote:
> So the question is if one of the justifications for moving the daemon
> into kernel space is that it's performance is crap, then I think it is
> useful to determine whether a fully optimized userspace daemon would
> be good enough.
>
Yeah. I
On Tue, Apr 28, 2015 at 1:19 PM, David Lang wrote:
> If the examples that are being used to show the performance advantage of
> kdbus vs normal dbus are doing the wrong thing, then we need to get some
> other examples available to people who don't live and breath dbus that 'so
> things right' so t
On Tue, 28 Apr 2015, Havoc Pennington wrote:
btw if I can make a suggestion, it's quite confusing to talk about
"dbus" unqualified when we are talking about implementation issues,
since it muddles bus daemon vs. clients, and also since there are lots
of implementations of the client bindings:
On Tue, Apr 28, 2015 at 10:48:10AM -0400, Havoc Pennington wrote:
> btw if I can make a suggestion, it's quite confusing to talk about
> "dbus" unqualified when we are talking about implementation issues,
> since it muddles bus daemon vs. clients, and also since there are lots
> of implementations
btw if I can make a suggestion, it's quite confusing to talk about
"dbus" unqualified when we are talking about implementation issues,
since it muddles bus daemon vs. clients, and also since there are lots
of implementations of the client bindings:
http://www.freedesktop.org/wiki/Software/DBusBi
On Mon, Apr 27, 2015 at 6:14 PM, Linus Torvalds
wrote:
> The real problems seem to be in dbus memory management (suggestion:
> keep a small per-thread cache of those message allocations) and to a
> smaller degree in the crazy utf8 validation (why the f*ck does it do
> that anyway?), with some lock
On Mon, Apr 27, 2015 at 6:00 PM, Linus Torvalds
wrote:
> If somebody wants to speed up dbus, they should likely look at the
> user-space code, not the kernel side.
To be more precise, your profile seems to show a lot of the gdbus
(glib bindings) user space code. (And the blocking version of this
On 04/28/2015 12:29 AM, David Lang wrote:
> On Mon, 27 Apr 2015, Lukasz Skalski wrote:
>
> aren't we being told that part of the reason for needing kdbus is that
> thousands, or tens of thousands of messages are being spewed out? how
> does limiting it to 128 messages represent real-life if this i
On 04/27/2015 11:32 PM, Linus Torvalds wrote:
> On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
>>
>> To perform tests I've created two simple apps:
>>
>> - server: http://fpaste.org/215157/
>> - client: http://fpaste.org/215156/
>
> So since Andy reported that dbus seems to be a few order
On 04/27/2015 10:08 PM, Andy Lutomirski wrote:
> On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
>> Hi All,
>>
>> On 04/23/2015 07:16 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Apr 23, 2015 at 09:46:22AM -0700, Andy Lutomirski wrote:
- There's still an open performance question. Namel
On Mon, 27 Apr 2015, Lukasz Skalski wrote:
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote:
On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
On 04/24/2015 04:19 PM, Havoc Pennington wrote:
On Fri, Apr 24, 2015 at 9:50 AM, Lukasz
On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds
wrote:
>
> IOW, all the people who say that it's about avoiding context switches
> are probably just full of shit. It's not about context switches, it's
> about bad user-level code.
Just to make sure, I did a system-wide profile (so that you can
act
On Mon, Apr 27, 2015 at 2:40 PM, Andy Lutomirski wrote:
>
> Change "USER" to "SESSION".
That works.
> Build with:
Hell no. I used
gcc client.c -o client $(pkg-config --cflags --libs gtk+-2.0)
instead. That worked.
>> That said, either you're running your test on a potato, or dbus is
>> se
On Mon, Apr 27, 2015 at 2:32 PM, Linus Torvalds
wrote:
> On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
>>
>> To perform tests I've created two simple apps:
>>
>> - server: http://fpaste.org/215157/
>> - client: http://fpaste.org/215156/
>
> So since Andy reported that dbus seems to be a
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
>
> To perform tests I've created two simple apps:
>
> - server: http://fpaste.org/215157/
> - client: http://fpaste.org/215156/
So since Andy reported that dbus seems to be a few orders of magnitude
too slow, I tried to build these apps to s
[resent without HTML]
On Apr 27, 2015 5:46 AM, "Michal Hocko" wrote:
>
> On Wed 22-04-15 12:36:12, Andy Lutomirski wrote:
> > On Apr 22, 2015 7:57 AM, "Michal Hocko" wrote:
> > >
> > > On Tue 21-04-15 11:11:35, Andy Lutomirski wrote:
> > > > On Tue, Apr 21, 2015 at 7:27 AM, Michal Hocko wrote:
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
> Hi All,
>
> On 04/23/2015 07:16 PM, Greg Kroah-Hartman wrote:
>> On Thu, Apr 23, 2015 at 09:46:22AM -0700, Andy Lutomirski wrote:
>>> - There's still an open performance question. Namely: is kdbus performant?
>>
>> Yes, I thought that was
On Mon, Apr 27, 2015 at 10:57:45AM +0200, Lukasz Skalski wrote:
> On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote:
> > On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
> >> On 04/24/2015 04:19 PM, Havoc Pennington wrote:
> >>> On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski
> >>>
1 - 100 of 362 matches
Mail list logo
