Community
cancel
Showing results for 
Search instead for 
Did you mean: 
GGK
Novice
1,747 Views

High CPU usage on gatttool disconnect

Jump to solution

Hi,

I am cross-posting this from stackoverflow as I think there are a few people using gatttool in this forum.

I am using bluez 5.3+ backported to linux 2.6 due to project restrictions on a custom device. I have noticed gatttool causes a very high cpu usage on disconnection. This is very easy to replicate. Use gatttool in interactive mode to connect to any BLE device and then disconnect. CPU usage is fine till you give the disconnect command. Observe CPU usage, gatttool will cross 70-80%. I can also replicate this on Ubuntu LTS. Has anyone had a go at fixing this?

Thanks.

1 Solution
GGK
Novice
174 Views

I guess I found what is wrong. Gatttool uses glib main event loop and so io channels are attached as sources to the default main context (read glib docs for more clarification). As an example in 'bluez/attrib/interactive.c' in function cmd_connect 'g_io_add_watch(iochannel, G_IO_HUP, channel_watcher, NULL)' is done. This function will return a gsource which has to be removed from watch once io channel is lost or deleted. In absence of this, glib will keep waiting on this io channel (fd) and cause EINVAL as return code. (My knowledge is patchy but I guess that's what happens). So when disconnecting the device this watch needs to be removed.

I do it in following way - define a new global - guint gsrc.

Change the line in cmd_connect to

gsrc = g_io_add_watch(iochannel, G_IO_HUP, channel_watcher, NULL);

After disconnection, in disconnect_io function at the end I do g_source_remove(gsrc);

This fixes gatttool cpu usage bug in interactive mode.

I did ask on IRC but I didn't get any replies.

View solution in original post

5 Replies
idata
Community Manager
174 Views

Hello gkopendev,

 

 

I do see an increase of the CPU consumed by gatttool however it does not reach 70-80%. Nevertheless, have you tried to change the niceness of the process, that should give it less priority therefore it should consume less CPU. Check http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/ http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/ to learn how to change the niceness level of a process.

 

 

Peter.
GGK
Novice
174 Views

Hi,

Thanks for your reply.

It starts at 30-40% and then rises to 70% or above and stays there. In any case, this seems like a bug because even while normal scanning(before connection and disconnection), while being connected the tool hardly takes 1%. It seems the cleanup code in disconnect_io function causes issues. I will try the niceness feature.

GGK
Novice
174 Views

In my case, changing priority only resulted in CPU falling to 60% which is still a lot!

idata
Community Manager
174 Views

In that case I believe the best option would be to report a bug to BlueZ since as you mentioned this issue is also replicable in Ubuntu. You can contact them in http://www.bluez.org/contact/ http://www.bluez.org/contact/.

 

 

Peter.
GGK
Novice
175 Views

I guess I found what is wrong. Gatttool uses glib main event loop and so io channels are attached as sources to the default main context (read glib docs for more clarification). As an example in 'bluez/attrib/interactive.c' in function cmd_connect 'g_io_add_watch(iochannel, G_IO_HUP, channel_watcher, NULL)' is done. This function will return a gsource which has to be removed from watch once io channel is lost or deleted. In absence of this, glib will keep waiting on this io channel (fd) and cause EINVAL as return code. (My knowledge is patchy but I guess that's what happens). So when disconnecting the device this watch needs to be removed.

I do it in following way - define a new global - guint gsrc.

Change the line in cmd_connect to

gsrc = g_io_add_watch(iochannel, G_IO_HUP, channel_watcher, NULL);

After disconnection, in disconnect_io function at the end I do g_source_remove(gsrc);

This fixes gatttool cpu usage bug in interactive mode.

I did ask on IRC but I didn't get any replies.

View solution in original post

Reply