From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Kaigai Kohei <kaigai@ak.jp.nec.com>
Cc: Guillaume Thouvenin <guillaume.thouvenin@bull.net>,
Andrew Morton <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
elsa-devel <elsa-devel@lists.sourceforge.net>,
Jay Lan <jlan@engr.sgi.com>, Gerrit Huizenga <gh@us.ibm.com>,
Erich Focht <efocht@hpce.nec.com>,
Netlink List <netdev@oss.sgi.com>
Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
Date: Thu, 3 Mar 2005 08:46:56 +0300 [thread overview]
Message-ID: <20050303084656.A15197@2ka.mipt.ru> (raw)
In-Reply-To: <42268201.80706@ak.jp.nec.com>; from kaigai@ak.jp.nec.com on Thu, Mar 03, 2005 at 12:18:25PM +0900
On Thu, Mar 03, 2005 at 12:18:25PM +0900, Kaigai Kohei (kaigai@ak.jp.nec.com) wrote:
> Hello, Guillaume
>
> I tried to measure the process-creation/destruction performance on 2.6.11-rc4-mm1 plus
> some extensiton(Normal/with PAGG/with Fork-Connector).
> But I received a following messages endlessly on system console with Fork-Connector extensiton.
>
> # on IA-64 environment / When an simple fork() iteration is run in parallel.
> skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30].
> skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30].
> skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30].
> :
>
> Is's generated at drivers/connector/connector.c:__cn_rx_skb(), and this warn the length of msg's payload
> does not fit in nlmsghdr's length.
> This message means netlink packet is not sent to user space.
> I was notified occurence of fork() by printk(). :-(
No, lengths are correct, but skb can be dropped due to misaligned sizes check.
> The attached simple *.c file can enable/disable fork-connector and listen the fork-notification.
> Because It's first experimence for me to write a code to use netlink, point out a right how-to-use
> if there's some mistakes at user side apprication.
>
> Thanks.
>
> P.S. I can't reproduce lockup on 367th-fork() with your latest patch.
I've sent that patch to Guillaume and upstream, hopefully it will be
integrated into next -mm release.
> Guillaume Thouvenin wrote:
> > ChangeLog:
> >
> > - Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE
> > in the CN_FORK_MSG_SIZE macro
> > - fork_cn_lock is declareed with DEFINE_SPINLOCK()
> > - fork_cn_lock is defined as static and local to fork_connector()
> > - Create a specific module cn_fork.c in drivers/connector to
> > register the callback.
> > - Improve the callback that turns on/off the fork connector
> >
> > I also run the lmbench and results are send in response to another
> > thread "A common layer for Accounting packages". When fork connector is
> > turned off the overhead is negligible. This patch works with another
> > small patch that fix a problem in the connector. Without it, there is a
> > message that says "skb does not have enough length". It will be fix in
> > the next -mm tree I think.
> >
> >
> > Thanks everyone for the comments,
> > Guillaume
>
> --
> Linux Promotion Center, NEC
> KaiGai Kohei <kaigai@ak.jp.nec.com>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <asm/types.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <linux/netlink.h>
>
> void usage(){
> puts("usage: fclisten <on|off>");
> puts(" Default -> listening fork-connector");
> puts(" on -> fork-connector Enable");
> puts(" off -> fork-connector Disable");
> exit(0);
> }
>
> #define MODE_LISTEN (1)
> #define MODE_ENABLE (2)
> #define MODE_DISABLE (3)
>
> struct cb_id
> {
> __u32 idx;
> __u32 val;
> };
>
> struct cn_msg
> {
> struct cb_id id;
> __u32 seq;
> __u32 ack;
> __u32 len; /* Length of the following data */
> __u8 data[0];
> };
>
>
> int main(int argc, char *argv[]){
> char buf[4096];
> int mode, sockfd, len;
> struct sockaddr_nl ad;
> struct nlmsghdr *hdr = (struct nlmsghdr *)buf;
> struct cn_msg *msg = (struct cn_msg *)(buf+sizeof(struct nlmsghdr));
>
> switch(argc){
> case 1:
> mode = MODE_LISTEN;
> break;
> case 2:
> if (strcasecmp("on",argv[1])==0) {
> mode = MODE_ENABLE;
> }else if (strcasecmp("off",argv[1])==0){
> mode = MODE_DISABLE;
> }else{
> usage();
> }
> break;
> default:
> usage();
> break;
> }
>
> if( (sockfd=socket(PF_NETLINK, SOCK_RAW, NETLINK_NFLOG)) < 0 ){
> fprintf(stderr, "Fault on socket().\n");
> return( 1 );
> }
> ad.nl_family = AF_NETLINK;
> ad.nl_pad = 0;
> ad.nl_pid = getpid();
> ad.nl_groups = -1;
Group should be CN_FORK_IDX to receive only fork's messages.
> if( bind(sockfd, (struct sockaddr *)&ad, sizeof(ad)) ){
> fprintf(stderr, "Fault on bind to netlink.\n");
> return( 2 );
> }
>
> if (mode==MODE_LISTEN) {
> while(-1){
> len = recvfrom(sockfd, buf, 4096, 0, NULL, NULL);
> printf("%d-byte recv Seq=%d\n", len, hdr->nlmsg_seq);
> }
> }else{
> ad.nl_family = AF_NETLINK;
> ad.nl_pad = 0;
> ad.nl_pid = 0;
> ad.nl_groups = 1;
>
> hdr->nlmsg_len = sizeof(struct nlmsghdr) + sizeof(struct cn_msg) + sizeof(int);
> hdr->nlmsg_type = 0;
> hdr->nlmsg_flags = 0;
> hdr->nlmsg_seq = 0;
> hdr->nlmsg_pid = getpid();
> msg->id.idx = 0xfeed;
> msg->id.val = 0xbeef;
> msg->seq = msg->ack = 0;
> msg->len = sizeof(int);
>
> if (mode==MODE_ENABLE){
> (*(int *)(msg->data)) = 1;
> } else {
> (*(int *)(msg->data)) = 0;
> }
> sendto(sockfd, buf, sizeof(struct nlmsghdr)+sizeof(struct cn_msg)+sizeof(int),
> 0, (struct sockaddr *)&ad, sizeof(ad));
> }
> }
Later today I will post finished connector.c with the all pending
patches in, and simple test program for anyone, who wants
to test fork() performace with and without fork's connector enabled.
Since Guillaume is busy, I will test it in my 2-way (1+1HT) CPU system.
--
Evgeniy Polyakov ( s0mbre )
next prev parent reply other threads:[~2005-03-03 5:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1109240677.1738.196.camel@frecb000711.frec.bull.fr>
2005-03-02 8:48 ` [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector Guillaume Thouvenin
2005-03-02 14:51 ` Paul Jackson
2005-03-02 17:48 ` Jesse Barnes
2005-03-02 15:50 ` Paul Jackson
2005-03-03 3:18 ` Kaigai Kohei
2005-03-03 5:46 ` Evgeniy Polyakov [this message]
2005-03-03 11:51 ` Evgeniy Polyakov
2005-03-03 12:20 ` Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050303084656.A15197@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=akpm@osdl.org \
--cc=efocht@hpce.nec.com \
--cc=elsa-devel@lists.sourceforge.net \
--cc=gh@us.ibm.com \
--cc=guillaume.thouvenin@bull.net \
--cc=jlan@engr.sgi.com \
--cc=kaigai@ak.jp.nec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).